7.30M

Категория:

Программное обеспечение

Похожие презентации:

Системы контроля версий

Занятие 5 Git – система контроля версий

Система контроля версий

GIT. Система контроля версий

Введение в GIT

Система контроля версий GIT

Основы Git

Git, GitHub

Инструменты разработки

ДополненнаяРеальность_ПродвинутыйУровень_Занятие1_ЗнакомствоСGIT

1.

Федеральное государственное бюджетное образовательное учреждение
высшего образования «МИРЭА – Российский технологический университет»
Детский технопарк «Альтаир»
Дополненная Реальность
Занятие 1. Работа с GIT
Хвостов Сергей Дмитриевич
Преподаватель Детского технопарка «Альтаир»

2.

Чат группы

3.

Как будут проходить занятия
Ваша активность на занятии важна!
1. На каждом занятии будет выставляться посещение.
2. Ваша работа во время занятия будет оцениваться.
В конце обучения должен быть предоставлен Итоговый Проект.

4.

Продвинутый уровень
Продвинутый уровень 01.12.2025-08.02.2026
Разработка проекта.
Разработка презентации проекта, а также полного текста работы.
Консультации по проекту.
Защита проекта 09.02.2026-22.02.2026
Подготовка к защите в рамках конференции.

5.

Система контроля версий
Система контроля версий (англ. Version Control System, VCS, СКВ) – это ПО,
предназначенное для отслеживания и управления изменениями файлов во времени,
позволяющее сохранять историю модификаций, возвращаться к предыдущим
состояниям, сравнивать изменения между версиями и координировать совместную
работу нескольких разработчиков над общей базой программного проекта.

6.

Характеристики СКВ
Ключевые характеристики СКВ:
1) версионирование: система сохраняет каждое зафиксированное изменение (коммит)
как отдельную версию, создавая полную историю эволюции проекта;
2) отслеживание изменений: регистрируется информация о том, что было изменено,
кем, когда и по какой причине (через комментарии к коммитам);

7.

Характеристики СКВ
3) восстановление: возможность откатиться к любой предыдущей версии файла или
всего проекта;
4)
параллельная
разработка:
поддержка
одновременной
работы
разработчиков через механизмы ветвления (branching) и слияния (merging);
множества

8.

Характеристики СКВ
5) разрешение конфликтов: инструменты для обработки ситуаций, когда несколько
разработчиков модифицируют один и тот же фрагмент кода.

9.

Типы СКВ
На сегодняшний день существуют следующие СКВ:
− локальные (RCS);
− централизованные (SVN, CVS, Perforce);
− распределённые (Git, Mercurial, Bazaar).

10.

Локальные СКВ
Все версии файлов хранятся только на одном компьютере.
Система просто сохраняет разные версии одного и того же файла в специальном
формате (часто в виде различий между версиями — diffs).
Нет понятия "проекта" как единого целого — каждая версия хранится отдельно для
каждого файла.

11.

Локальные СКВ «+»
1. Простота установки и использования.
2. Подходит для одиночной работы, когда не нужно сотрудничать с другими.

12.

Локальные СКВ «-»
1. Нет совместной работы.
2. Нет сетевого резервного копирования — если компьютер сломается, история
изменений теряется.
3. Сложно отслеживать взаимосвязанные изменения в нескольких файлах.

13.

Централизованные СКВ
Есть один центральный сервер, на котором хранится весь репозиторий (история,
файлы, метаданные).
Каждый разработчик получает рабочую копию с сервера, вносит изменения и
отправляет их обратно.
Изменения нельзя отправить без подключения к серверу.

14.

Централизованные СКВ «+»
1. Централизованное управление: легко увидеть, кто работает над чем.
2. Простая модель для понимания: один источник истины.
3. Поддержка прав доступа и аудита.

15.

Централизованные СКВ «-»
1. Одна точка отказа: если сервер упадёт — никто не сможет коммитить или видеть
историю.
2. Нельзя работать офлайн (нельзя фиксировать коммиты без сервера).
3. Слияние изменений от разных разработчиков может быть сложным.
4. Более медленные операции (всё через сеть).

16.

Распределённые СКВ
У каждого разработчика есть полная копия всего репозитория, включая всю историю
изменений.
Можно делать коммиты локально, даже без интернета.
Чтобы обмениваться изменениями, разработчики синхронизируют свои репозитории
(через push / pull / fetch).
Нет "главного сервера" по умолчанию — но часто используют общий репозиторий
(например, на GitHub).

17.

Распределённые СКВ «+»
1. Полная автономность: работа офлайн, быстрые коммиты.
2. Надёжность: если сервер исчезнет — любой участник команды может восстановить
проект.
3. Гибкость ветвления и слияния: создание и переключение веток почти мгновенное.
4. Целостность данных: всё хешируется (SHA-1 в Git), невозможно подделать историю
без обнаружения.
5. Поддержка сложных workflow (например, Git Flow, GitHub Flow).

18.

Распределённые СКВ «-»
1. Более сложная модель для новичков.
2. Требует понимания распределённой архитектуры.
3. История может стать запутанной при плохом стиле коммитов.

19.

Какая СКВ лучше?
Характеристика
Локальные
Централизованные
Распределённые
Хранение
истории
Только на 1 ПК
Только на сервере
У каждого
разработчика
Работа офлайн
Да
Нет
Да
Совместная
работа
Нет
Да
Да
Отказоустойчиво
сть
Низкая
Низкая
Высокая
Скорость
коммитов
Быстро
Медленно (через
сеть)
Очень быстро
(локально)
Гибкость
ветвления
Нет
Ограниченная
Очень высокая

20.

Какая СКВ лучше?
RCS (локальная) — устаревший, подходит только для личных заметок.
SVN (централизованная) — ещё жив, но уступает Git в гибкости и скорости.
Git (децентрализованная) — современный стандарт, особенно в open-source и agileразработке.

21.

Выбор GIT
В современной практике разработки ПО система контроля версий Git занимает
доминирующее положение, являясь стандартом для управления исходным кодом
проектов различного масштаба и сложности.
Git представляет собой распределённую систему контроля версий (Distributed Version
Control System, DVCS), разработанную Л. Торвальдсом в 2005 г. для управления
разработкой ядра ОС Linux

22.

Для чего изначально создали GIT
Git представляет собой распределённую систему контроля версий (Distributed Version
Control System, DVCS), разработанную Л. Торвальдсом в 2005 г. для управления
разработкой ядра ОС Linux

23.

GIT
Принципиальным отличием Git от централизованных систем контроля версий является
распределённая архитектура, в рамках которой каждый разработчик располагает
полноценной копией репозитория, включающей всю историю изменений проекта.
Данный подход обеспечивает высокую степень автономности и отказоустойчивости
системы.

24.

Архитектура GIT
В основе функционирования Git лежит модель хранения данных, базирующаяся на
направленном ациклическом графе (Directed Acyclic Graph, DAG) объектов.

25.

Архитектура GIT
4 типа объектов:
blob (бинарное содержимое файлов);
tree (древовидная структура папок проекта);
commit (коммит, фиксация изменений – это объект, который содержит в себе имя
автора, время коммита и объект дерева корневой папки проекта);
tag (именованная ссылка на конкретный коммит).

26.

Архитектура GIT
Каждый объект идентифицируется уникальным хэш-значением SHA-1, что гарантирует
целостность данных и возможность верификации содержимого.

27.

SHA-1
Это 160-битный (20-байтовый) криптографический хеш, вычисляемый по содержимому
данных с использованием алгоритма SHA-1 (Secure Hash Algorithm 1). В системе Git это
значение используется как уникальный идентификатор для каждого объекта
репозитория (файлов, папок, коммитов и тегов).

28.

Трёхуровневая архитектура GIT
Процесс фиксации изменений в Git реализован через трёхуровневую архитектуру:
рабочий каталог (working directory);
промежуточная область (staging area или index);
репозиторий (repository).

29.

Трёхуровневая архитектура GIT
Рабочий каталог содержит текущую версию файлов проекта, промежуточная область
аккумулирует изменения, подготовленные к фиксации, а репозиторий хранит историю
всех зафиксированных состояний проекта.
Репозиторий может быть локальным и удалённым

30.

Ветвление в GIT
Реализация ветвления (branching) в Git способствует применению различных стратегий
разработки.Ветка представляет собой подвижный указатель на определённый
коммит, что делает операции создания и переключения между ветками практически
мгновенными, независимо от размера проекта.

31.

Слияние
Механизм слияния (merging) позволяет интегрировать изменения из различных линий
разработки, применяя алгоритмы с автоматическим разрешением конфликтов.

32.

Fetch, pull и push
Распределённая
природа
репозиториев,
между
Git
предполагает
которыми
наличие
осуществляется
множества
удалённых
синхронизация
изменений
посредством операций
fetch, pull и push.
Несмотря на отсутствие жёсткой иерархии, в практике разработки часто применяется
модель с центральным репозиторием, выполняющим роль канонического источника
кода проекта.

33.

Протоколы передачи данных
Git поддерживает различные протоколы передачи данных, включая HTTP/HTTPS,
SSH и собственный протокол Git.
Эффективность сетевых операций достигается благодаря применению алгоритмов
дифференциальной компрессии и передачи только изменённых объектов.

34.

Важный аспект работы!
Формирование информативной истории коммитов (снимков состояний проекта с
фиксацией изменений в файлах с идентификацией авторов этих изменений).
Рекомендуется применение атомарных коммитов, охватывающих
логически завершённые изменения, и составление содержательных сообщений,
описывающих суть внесённых модификаций.

35.

Ключевые преимущества Git
высокая производительность операций (благодаря локальному характеру
большинства действий);
надёжность
и
целостность
данных
(обеспечивается
криптографическим
хешированием);
гибкость в организации рабочих процессов;
эффективность механизма ветвления и слияния;
поддержка нелинейной разработки с параллельными линиями изменений.

36.

Установка Git
Проверим на компьютере наличие редактора кода Visual Studio Code.
Установили Python в качестве расширения.

37.

Установка Git

38.

Установка Git
Проверили, что Git установлен на устройстве.
В уже установленной среде выбрали Visual Studio Code редактором для Git по
умолчанию.
Установили, что имя начальной ветки будет задаваться, как main

39.

Установка Git
После установки Git запустим терминал – пользовательский интерфейс для
взаимодействия (в ОС Windows – Git Bash). ПКМ по рабочей области.
Здесь же определим в глобальных настройках Git имя пользователя, которым будут
подписываться изменения – Sergey Khvostov

40.

Установка Git
Проверим настройки.
Определим правильный
формат строк для Windows.
Дальше зададим общую для всех ОС команду, которая позволит избежать
нечитаемых строк в неправильной кодировке .

41.

Создание локального репозитория
Репозиторий в Git – это хранилище проекта, содержащее все его файлы, историю
изменений и другую служебную информацию.
Это хранилище может выступать в роли:
а) локальной папки на компьютере разработчика;
б) папки на удалённом сервере.
Репозиторий позволяет отслеживать версии кода, управлять изменениями и работать в
команде.
Создадим свой локальный репозиторий.

42.

Создание локального репозитория
На ПК под управлением ОС Windows cоздадим на Рабочем Столе папку, назовем её
вашими инициалами.
Правым щелчком на значке папки вызовем контекстное меню и в нём выберем
команду «Open Git Bash here»

43.

Создание локального репозитория
Проинициализируем репозиторий.
Был создан локальный репозиторий Git. Убедимся в этом, открыв папку в Проводнике,
а в ней – папку .git

44.

Создание файла README.md
Откроем редактор Visual Studio Code, выполним команду File, Open, Folder… и в
диалоговом окне выберем созданную папку

45.

Отслеживание файлов в репозитории Git
Файлы в репозитории могут быть в одном из двух возможных состояний:
1. Неотслеживаемые (untracked) – без контроля со стороны Git, изменения в них не
будут добавлены в коммит. Это любые файлы, которые не входили в последний
коммит и не подготовлены к текущему коммиту.
2. Отслеживаемые (tracked) – о них Git знает и следит за изменениями в них.
Отслеживаемые файлы, в свою очередь, могут находится в следующих состояниях

46.

Виды отслеживаемых файлов
1. Неизменённый (unmodified) – с момента последнего коммита в файле не было
никаких изменений.
2. Изменённый (modified) – с последнего коммита в файле были произведены какието изменения.
3. Подготовленный к коммиту (staged) – в файл внесены изменения, затем
проиндексированы, и позже эти изменения будут добавлены в следующий коммит.

47.

Виды отслеживаемых файлов

48.

Работа с репозиторием
Проверим текущее состояние репозитория
Добавим файл README.md в отслеживаемые

49.

Работа с репозиторием
Чтобы проверить, что файл README.md теперь отслеживается, выполним снова
команду git status. При этом Git ответит, что коммитов ещё нет, но теперь файл
README.md – отслеживаемый

50.

Работа с репозиторием
Внутри файла README.md напишем строку, используя синтаксис языка Markdown
Сохраним изменения в файле (File, Save) и повторим команду git status. Git отследит,
что после последнего сохранения проекта файл изменился

51.

Работа с репозиторием
С помощью команды git add добавим изменённый файл README.md в индекс коммита,
после чего снова проверим статус репозитория.

52.

Коммит проекта в Git
Коммит (commit) – это процедура, при которой делается снимок файла (папки, всего
репозитория) в текущем состоянии.
В самом простом случае (без ответвлений со слияниями и откатов) развитие проекта –
это линейная последовательность коммитов.

53.

Коммит проекта в Git
Какие возможности коммит в Git даёт разработчикам:
отслеживать, кто, что и когда изменял;
возвращаться к предыдущему состоянию (снимку);
переписывать историю файлов.

54.

Коммит проекта в Git
Команда git commit создаёт новый коммит с файлами из индекса. Она откроет
текстовый редактор Vim для ввода сообщения коммита. Также с этой командой можно
использовать флаги:
-m позволяет написать сообщение вместе с командой, не открывая редактор
(например, git commit -m "add README.md");

55.

Коммит проекта в Git
-a переносит все отслеживаемые файлы в область подготовленных файлов и
включает их в коммит (позволяет пропустить ввод git add перед коммитом);
--amend заменяет последний коммит новым изменённым (что бывает полезно, если
вы неправильно набрали сообщение последнего коммита или забыли включить в
него какие-то важные файлы).

56.

Советы по созданию коммита в Git
1. Создавайте коммиты как можно чаще.
2. Одно изменение = один коммит: не помещайте все не связанные между собой
изменения в один коммит; разделите их, чтобы было проще откатиться.

57.

Советы по созданию коммита в Git
4. Формат сообщений: заголовок должен быть в повелительном наклонении, меньше
50 символов в длину и должен логически дополнять фразу «this commit will…»
(например, this commit will fix bugs – этот коммит исправит баги).
5. Сообщение должно пояснять, почему был сделан коммит, а сам коммит
показывает, что изменилось.
6. Если у вас много незначительных изменений, хорошим тоном считается делать
небольшие коммиты при разработке, а при добавлении в большой репозиторий
объединять их в один.

58.

Коммит проекта в Git
Закоммитим последние изменения.
Выполним команду git status, чтобы убедиться, что все файлы попали в снимок проекта

59.

История коммитов проекта
Выполните команду, результатом будет вывод на экран истории коммитов проекта
Эти коммиты создавались в порядке от самого нижнего к самому верхнему.
Коммиты хранят состояние файловой системы в определённый момент времени и
указатели на предыдущие коммиты. Каждый коммит содержит уникальную
контрольную сумму (хеш) – идентификатор, который Git использует, чтобы ссылаться на
коммит.

60.

Как отслеживается история
Чтобы отслеживать историю, Git хранит указатель HEAD, который указывает на первый
коммит (следуем по цепочке коммитов в обратном порядке, чтобы попасть к
предыдущим коммитам).
Каждый раз, когда записывается новый коммит, HEAD смещается и указывает на него.
Можно ссылаться на коммит либо через его контрольную сумму, либо через его
позицию относительно HEAD.

61.

Как отслеживается история
Чтобы посмотреть всю информацию о коммите, выполним команду git log без флага.
В такой записи можно увидеть полный хеш коммита, автора и дату с точным временем
создания.

62.

Как отслеживается история
Изменим произвольно содержимое файла README.md
Создадим коммит с ошибкой в подписи

63.

Как отслеживается история
Выведем историю, с помощью git log

64.

Изменение последнего коммита
Исправим подпись последнего коммита по команде git commit --amend -m «error»
Проверим, что файл README.md откатился к предыдущей версии и у коммита
изменился хеш (так как Git отменил прошлый коммит и создал новый, исправленный).

65.

Изменение последнего коммита
Добавим новый файл errors.md .
В последний коммит проекта с сообщением «error» .
Полная историю коммитов.

66.

Переключение на коммит
Найдем хеш прошлого коммита, к которому хотим вернуться (достаточно первых 7
символов).
Переключимся на нужный коммит с помощью команды git checkout хеш_коммита.

67.

Переключение на коммит
Откроем Visual Studio Code и убедимся, что в файле README.md написан только
заголовок «# Hello, world!», а файла errors.md больше нет в папке.
Проект откатился к состоянию, когда нового файла ещё нет, а в README.md был только
заголовок .
Проверим историю проекта – увидим только один этот коммит. Коммиты, сделанные
позже, отображаться не будут

68.

Переключение на коммит
Вызовем команду git log с флагом --all.
Git покажет всю историю проекта, вне зависимости от того, на каком коммите сейчас
находитесь

69.

Переключение на коммит
Проверим, что вернулись к последней версии проекта с помощью команды git log -oneline

70.

GitHub
GitHub – самая популярная в мире площадка для облачного хранения кода и
совместной командной разработки. Но у неё, конечно, есть множество альтернатив,
например, платформы GitLab, Bitbucket, mos.hub, а также собственных серверных
решений

71.

Основные функции GitHub
Каждый проект в GitHub называется репозиторием (или «репо»).
Репозиторий содержит:
1. Все файлы проекта;
2. Полную историю изменений (коммитов);
3. Ветки, теги, настройки и документацию.

72.

Совместная работа (collaboration)
Любой участник может:
1. Скачать проект (clone);
2. Внести изменения;
3. Отправить свои правки на обсуждение (pull request);
4. Обсудить код, предложить улучшения, найти баги.
5. GitHub автоматически сравнивает версии кода и помогает объединить их.

73.

Fork — копия чужого проекта
Если у вас нет прав на чужой репозиторий — вы можете сделать форк (fork).
Это создаёт личную копию проекта в вашем аккаунте.
Вы работаете над ней, а потом предлагаете изменения автору через pull request.

74.

Issues — задачи
Issues — это как задачи для команды:
«Нужно добавить кнопку»;
«Программа падает при вводе нуля»;
«Планируем новую фичу».
Каждая задача имеет:
Номер (например, #42);
Автора;
Статус (открыта/закрыта);
Комментарии, метки, исполнителя.

75.

Pull Request (PR) — предложение изменений
Это запрос на слияние вашей ветки в основную.
До слияния:
1. Команда просматривает код (code review);
2. Обсуждает детали;
3. Может попросить исправить что-то.
После одобрения — изменения попадают в основной проект.

76.

README.md как визитка проекта
GitHub автоматически показывает файл README.md на главной странице репозитория.
В нём обычно пишут:
1. Что делает проект;
2. Как его запустить;
3. Кто автор;
4. Лицензию и т.д.
Пишется на Markdown — простом языке разметки.

77.

GitHub и Git разные понятия
Git
GitHub
Программа на вашем компьютере
Веб-сервис в интернете
Работает локально
Требует интернета
Не требует аккаунта
Нужен аккаунт на github.com
Создан Линусом Торвальдсом
Создан компанией GitHub

78.

Аккаунт на GitHub

79.

Аккаунт на GitHub

80.

Вход в аккаунт через консоль
Ключ SSH – это криптографический безопасный идентификатор – длинный пароль,
используемый для авторизации. GitHub использует ключи SSH, чтобы вы могли
загружать файлы в репозиторий без необходимости каждый раз вводить свои логин и
пароль

81.

Вход в аккаунт через консоль
SSH-ключ – это, на самом деле, пара криптографических ключей (закрытого и
открытого), используемая для безопасной аутентификации при подключении к
удаленным серверам по протоколу SSH, заменяя пароль. Закрытый ключ (private key)
хранится в секрете на вашем компьютере, а открытый ключ (public key) размещается на
сервере, к которому вы подключаетесь. Сервер использует эту пару для проверки того,
что вы являетесь владельцем закрытого ключа, который соответствует открытому
ключу на сервере, обеспечивая тем самым безопасное соединение.

82.

Вход в аккаунт через консоль
Откроем терминал и выполним команду ssh-keygen. Программа спросит, куда
сохранить файл с ключом и предложит дважды ввести пароль для этого ключа. На этом
этапе лучше оставить все настройки по умолчанию

83.

Вход в аккаунт через консоль
Найдем
в
терминале
строчку
«Your
public
key
has
been
saved
in
/c/Users/user/.ssh/id_x.pub».
Здесь важен путь, по которому сохранился ключ. Скопируем окончание пути, начиная с
/.ssh

84.

Вход в аккаунт через консоль
Выполним команду cat ~/.ssh/id_x.pub, где после волнистой линии вставим путь до
вашего pub-файла, который только что скопировали.
На экране появится длинный набор символов, строка будет начинаться с ssh-rsa.
Скопируем в буфер обмена весь этот набор символов – это и есть SSH-ключ

85.

Вход в аккаунт через консоль
Осталось добавить его в наш профиль на GitHub.
В браузере перейдем по ссылке https://github.com/settings/keys

86.

Вход в аккаунт через консоль
В открывшейся странице нажмите кнопку
New SSH key.
В открывшейся форме в поле Title введем
название для ключа.
В большое поле ниже вставим длинный
набор символов, который только что
скопировали
из
терминала.
Нажмем
кнопку Add SSH key.
Теперь ПК связан с профилем на GitHub

87.

Связка локального и удаленного репозиториев
Перейдем по ссылке https://github.com/new
В поле Repository name введем название удалённого
репозитория. Название может быть любым, но
использовать можно только латинские буквы и
символы. Принято, чтобы название удалённого
репозитория совпадало с названием локальной
папки
с
проектом
на
компьютере.
Назовем
репозиторий соответственно.
Убедимся, что выбран вариант Public. Нажмем на
кнопку Create repository

88.

Связка локального и удаленного репозиториев
На открывшейся странице будет много
текста и разных команд.
Нужна
только
ссылка
на
новый
репозиторий.
Найдем ссылку на новый репозиторий.
В этой строке выберем переключатель
«SSH» и нажмем на иконку двух
квадратов в конце этой строки –
ссылка на удалённый репозиторий
будет скопирована в буфер обмена

89.

Связка локального и удаленного репозиториев
Откроем терминал для папки с локальным репозиторием. Проверим, что к этой папке ещё
не привязан никакой удалённый репозиторий

90.

Связка локального и удаленного репозиториев
Создадим связь между локальным и удалёнными репозиториями с названием origin.
Выполним команду git remote add origin SSH_ссылка_на_папку_удалённого_репозитория
Проверим наличие связей у папки репозитория ещё раз

91.

Связка локального и удаленного репозиториев
Для отправки чего-либо в удалённый репозиторий нужно воспользоваться командой git
push -u имя_связи main.
Отправим проект в удалённый репозиторий. После этого увидим отчёт, в котором Git
подробно сообщает, что он сделал

92.

Связка локального и удаленного репозиториев
Убедимся, что проект действительно опубликовался на GitHub, для чего вернемся на
GitHub, где копировали ссылку, и обновим эту страницу. На ней появились два файла в
проекте: README.md и errors.md

93.

Связка локального и удаленного репозиториев
Найдем
в
веб-интерфейсе
GitHub
надпись «4 commits» и нажмем на неё.
На открывшейся странице увидим всю
историю проекта почти так же, как
видели её до этого в терминале.
Сверху свежие коммиты, а внизу более
старые.
Видны
дата,
автор,
хеш
коммита. На каждый из коммитов
можно нажать, чтобы посмотреть, что
именно было изменено

94.

Связка локального и удаленного репозиториев
Если нажать на вкладку Code, то будет возврат к просмотру всех файлов проекта. На
каждый из них тоже можно нажать и увидеть содержимое. Файл с названием README.md.
GitHub автоматически распознаёт и выводит его содержимое на главной странице
репозитория

95.

Связка локального и удаленного репозиториев
Чтобы
просмотреть
все
созданные
репозитории, можно нажать на своё имя
пользователя вверху, перед названием
репозитория. Откроется главная страница
профиля. Здесь видны личные данные,
график
активности
и
последние
несколько репозиториев, над которыми
была работа.
Во вкладке Repositories будут все когдалибо созданные в профиле репозитории

96.

Работа с ветками
Ветка – опция в Git, которая позволяет создавать параллельно реализуемые клоны
проекта, когда:
над проектом работает несколько человек;
каждый делает свою задачу;
чтобы не мешать друг другу, каждый работает в своей ветке;
когда задача готова, то всё сливается в основную ветку.

97.

Работа с ветками
Использование веток:
помогает избежать поломок в основном проекте, пока функция не готова;
избавляет от конфликтов, когда несколько человек исправляют одну и ту же часть поразному.

98.

Работа с ветками
Создадим ветку с названием new-branch. Выполним git branch, в терминале будут уже два
имени

99.

Работа с ветками
Теперь переключимся на новую ветку. Для этого наберем команду переключения git
checkout с именем ветки, в которую хотим переключиться

100.

Работа с ветками
Откроем страницу репозитория на GitHub, найдем все
ветки. В выпадающем списке можно переключать
проект с одной ветки на другую.
Рядом с выпадающим списком есть надпись «2
branches».
Нажмем на кнопку «2 branches», откроется страница со
всеми ветками. Тут видна ветка по умолчанию, а также
наглядно показано, в какой из веток есть изменения.
В этом случае в ветке new-branch есть один коммит,
которого нет в main

101.

Работа с ветками

102.

Работа с ветками
Просмотрим историю любой ветки в терминале

103.

Работа с ветками
Смерджим ветки new-branch

104.

Работа с ветками
Обновим проект на GitHub. Выполним команду git push. В этот раз можно не писать -u
origin main. Это дополнение нужно только первый раз, когда отправляем новую ветку в
GitHub. Git уже знает, что и куда отправлять

105.

Приёмы командной работы в Git и Github
Командная работа в Git и GitHub – это совместная реализация проектов несколькими
разработчиками, при которой Git используется в качестве системы контроля версий
локальных хранилищ отдельных участников команд, а GitHub – как общее удалённое
хранилище для интеграции кода и коллективной работы над ним. Это позволяет командам
работать параллельно над разными задачами в проекте, использовать ветки для изоляции
изменений и последующего корректного слияния.

106.

Приёмы командной работы в Git и Github
При командной разработке важно уметь:
работать с коммитами;
отправлять изменения из локального хранилища в удалённый репозиторий
проекта (обновлять проект);
синхронизировать локальные и удалённый репозитории;
настраивать видимость файлов и папок репозитория для СКВ;
создавать задачи (issues);
отправлять изменения в удаленный репозиторий через pull request, который
предполагает обсуждение и код-ревью.

107.

Игнорирование файлов при публикации коммита
Файл .gitignore – это файл-настройка, который создаётся в папке проекта. В нём
указывается, какие файлы нужно игнорировать при публикации на GitHub.
При этом:
имя файла должно начинаться с точки, а в конце не должно быть никакого иного
расширения;
правила игнорирования сработают только для файлов, не добавленных в индекс,
неотслеживаемых, т.е. до команды git add.

108.

Ведение задач Issues
Issues – это система ведения задач в GitHub, облегченный вариант трекера [8].
Используются в следующих ситуациях:
сбор обратной связи от пользователей по ошибкам;
планирование доработки проекта;
обсуждение внутри каждой задачи;
маркировка задач разными лейблами, сбор задач в группы;
назначение исполнителя для задачи.

109.

Ведение задач Issues

110.

Запросы на слияние pull request
Pull request – это запросы на слияние, который предполагает обсуждение и код-ревью.
Удобный способ предложить свои изменения в открытый командный проект.
Используется в следующих ситуациях:
чтобы не засорять историю проекта спорными коммитами;
для внесения изменений не в свой проект.

111.

Запросы на слияние pull request
При наличии прав доступ к репозиторию внести в проект новый запрос на слияние
можно через «New Pull Request», далее следует описать суть изменений и отправить на
кодревью через «Create Pull Request».
При отсутствии прав доступа к репозиторию предложить изменения в проект можно
следующим образом: сделать fork репозитория, выбрать «Open Pull Request», выбрать
источник изменений через compare across forks, создать «New Pull Request».

112.

Запросы на слияние pull request
Запросы pull request нельзя удалить на GitHub, их можно только закрыть.
Код-ревью – это процесс проверки кода на ошибки, работоспособность и соответствие
внутренним правилам разработки команды.

113.

Запросы на слияние pull request
После нажатия кнопки «Create pull request» откроется интерфейс создания pull
request, похожий на тот, что видели при создании issue. Нужно написать заголовок и
добавить описание того, что вы предлагаете изменить. В правой колонке есть новая
настройка Reviewers.
В ней, если у вас есть права на работу в этом репозитории, можно выбрать того,
кто должен провести код-ревью изменений.

114.

GitHub Desktop
GitHub
Desktop
—
это
бесплатное
приложение
с
графическим
интерфейсом,
разработанное компанией GitHub, которое позволяет работать с системой контроля
версий Git без использования командной строки.

115.

GitHub Desktop
Функция
Что делает
Можно создать новый
Создание репозитория
локальный проект
прямо в приложении
Показывает, какие
Отслеживание
файлы изменились,
изменений
добавлены или удалены
Зачем это нужно
Функция
Не нужно git init в
терминале
Создание репозитория
Видно всё наглядно
Отслеживание
изменений
Подготовка коммитов
(staging)
Выбрали файл, и он
попадает в коммит
Заменяет команду git
add
Подготовка коммитов
(staging)
Создание коммитов
Вводим описание,
нажимаем «Commit»
Не нужно git commit -m
"..."
Создание коммитов
Создание и
переключение веток
Есть кнопка «New
branch», список веток
Без git checkout и git
branch
Создание и
переключение веток
Публикация на GitHub
Кнопка «Publish
repository» и проект
появляется на GitHub
Не нужно настраивать
SSH и писать git remote Публикация на GitHub
add