Компоненты потока GitHub

Завершено

В этом уроке мы просматриваем следующие компоненты потока GitHub:

• Ветви
• Коммиты
• Пулл-реквесты
• Поток GitHub
• Поток Git (Git flow)

Компоненты потока GitHub

Прежде чем перейти к рабочим процессам GitHub, полезно понять, что поток GitHub строится непосредственно на базовых концепциях Git.

Git предоставляет средства для отслеживания изменений в коде и управления ими с течением времени. GitHub основывается на этом, упрощая использование этих инструментов благодаря таким функциям, как ветки, коммиты, pull-запросы и визуальные интерфейсы для коллаборации. Начнем с того, как эти понятия работают в GitHub.

Что такое ветви

В последнем разделе мы создали новый файл и новую ветвь в репозитории.

Ветви являются важной частью интерфейса GitHub. Они позволяют вносить изменения без влияния на ветвь по умолчанию.

Ваша ветвь — это безопасное место для экспериментов с новыми функциями или исправлениями. Если вы ошибаетесь, вы можете вернуть изменения или отправить дополнительные изменения, чтобы исправить ошибку. Ваши изменения не отобразятся в ветви по умолчанию, пока вы не объедините свою ветвь.

Примечание.

Кроме того, вы можете создать новую ветвь и проверить ее с помощью git в терминале. Команда будет git checkout -b newBranchName

Что такое коммиты

В предыдущем уроке вы добавили новый файл в репозиторий, зафиксировав изменения. Давайте кратко рассмотрим, что такое коммиты.

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

Вы можете создать коммит с помощью Git в вашем терминале:

git commit -m "Add a helpful commit message"

В репозитории Git файл может существовать в нескольких допустимых состояниях, так как он проходит через процесс управления версиями. Основные состояния для файла в репозитории Git — untracked и Tracked.

Без отслеживания: начальное состояние файла, когда он еще не является частью репозитория Git. Git не знает о своем существовании.

Отслеживаемый файл: отслеживаемый файл — это тот, который Git активно отслеживает. Он может находиться в одном из следующих подстатов:

• Не изменено: файл отслеживается, но он не был изменен с момента последней фиксации.
• Изменено: Файл изменён после последней фиксации, но эти изменения ещё не подготовлены для следующей фиксации.
• Подготовлено: файл был изменен, и изменения были добавлены в область индексирования (также называется индексом). Эти изменения готовы к выполнению.
• Зафиксировано: файл находится в базе данных репозитория. Он представляет последнюю зафиксированную версию файла.

Эти состояния помогают вашей команде понять состояние каждого файла и где он находится в процессе управления версиями.

Что такое запросы на включение изменений?

Pull request — это механизм, сигнализирующий о готовности коммитов из одной ветви к объединению в другую ветвь.

Участник команды, отправляющий pull request, просит одного или нескольких рецензентов проверить код и утвердить мердж. Рецензенты могут комментировать изменения, добавлять свои собственные или использовать сам пулл-реквест для дальнейшего обсуждения.

GitHub также поддерживает черновые запросы на вытягивание, что позволяет открыть запрос на вытягивание, который еще не готов к просмотру.

После утверждения изменений, при необходимости, исходная ветвь pull request (ветвь сравнения) объединяется с базовой ветвью.

Теперь, когда вы узнали, как работают ветки, коммиты и pull запросы, давайте посмотрим, как они объединяются в GitHub Flow.

Процесс работы в GitHub

Поток GitHub — это простой поток работы, который позволяет безопасно вносить изменения и делиться ими. Это отлично подходит для испытания идей и совместной работы с вашей командой с помощью веток, pull-запросов и слияний.

Примечание.

GitHub Flow является одним из нескольких популярных рабочих процессов. Другие включают поток Git и разработку на основе магистралей.

Теперь, когда мы знаем основы GitHub, мы можем пройти по потоку GitHub и его компонентам.

1. Начните с создания ветви, чтобы изменения, функции или исправления не влияли на основную ветвь.
2. Затем внесите изменения в ветке. Если рабочий процесс поддерживает его, вы можете развернуть изменения из этой ветви, чтобы протестировать их перед слиянием.
3. Теперь откройте пулл-реквест, чтобы получить обратную связь и начать проверку.
4. Затем просмотрите комментарии и внесите необходимые обновления на основе отзывов вашей команды.
5. Наконец, после того как вы уверены в изменениях, получите утверждение и объедините пулл-реквест в основную ветвь.
6. После этого удалите ветвь, чтобы сохранить репозиторий чистым и избежать использования устаревших ветвей.

Поток Git (Git flow)

Хотя GitHub Flow — это упрощенный рабочий процесс, предназначенный для непрерывной доставки, Git Flow — это более структурированная модель ветвления, часто используемая в средах, ориентированных на релизы. Поток Git существует дольше, чем GitHub Flow, и вы всё ещё можете встречать термин master, используемый вместо main в качестве ветви по умолчанию.

Изображение Винсента Дрисена, из "Успешной модели ветвления Git"

Типы ветвей потока Git

Git Flow использует несколько постоянных и временных веток.

• master: всегда отражает готовый к работе код.
• разработка: Содержит последние разработки для следующего выпуска.
• feature/*: используется для создания новых фич; создаётся ответвление от develop и объединяется обратно после завершения.
• release/*: подготавливает новый рабочий выпуск из develop; разрешает окончательное тестирование и исправление незначительных ошибок.
• исправление/*: используется для быстрого исправления рабочих проблем; ветвление от master.

Принцип работы процесса потока Git

1. Разработчики создают ветви компонентов из develop создания новых функций.
2. Когда пришло время для релиза, создается release branch от develop. Это изолирует работу по подготовке выпуска, чтобы разработка продолжалась непрерывно.
3. Исправления ошибок можно добавлять в ветвь релиза, но значительные функции должны ждать будущего релиза.
4. После того, как ветвь выпуска готова, она объединяется в master и помечается номером версии. GitHub может использовать эти теги для создания заметок о выпуске.
5. Для поддержания актуальности, ту же ветвь выпуска необходимо объединить обратно в develop.
6. Если возникает критическая ошибка в продакшене, создается ветка hotfix на основе master. После исправления он сразу объединяется с master и develop.

Когда следует использовать поток Git

• Лучше всего подходит для проектов с запланированными или версионированными выпусками
• Полезно при обслуживании нескольких рабочих версий (например, долгосрочных ветвей поддержки)
• Идеально подходит для более медленных, более структурированных циклов разработки (например, корпоративных или регулируемых сред)
• Считается более "тяжелым" чем GitHub Flow из-за дополнительного управления филиалами

Примечание.

Git flow предполагает коммиты слияния для интеграции веток. Использование rebase или слияний squash может повлиять на структуру ветви и отслеживание истории изменений.

Для многих команд, использующих GitHub, поток GitHub проще и быстрее. Но если ваша команда ценит предсказуемость и нуждается в большем планировании релиза, Git flow может больше подходить.

Поздравляю! Вы только что прошли полный поток GitHub и изучили, как поток Git предлагает структурированную альтернативу для проектов, управляемых выпусками.

Давайте перейдем к следующему разделу, в котором мы рассмотрим различия между вопросами и обсуждениями.