Командная работа без путаницы: разбираем стратегии ветвления в Гите

Вступление

Гит стал де-факто промышленным стандартом для системы контроля версий в создании программного обеспечения. О том, что такое гит и как начать, почитайте вначале мою статью об этом. Прочитали? Отлично, поехали дальше! Нравится нам или нет, но инструмент, который Линус Товальдс создал, не собирается уходить на пенсию. Поэтому имеет смысл поговорить о том, как работать распределенным командам в гите и какую стратегию ветвления для этого выбрать. И это вопрос вовсе не праздный. Часто в ситуации, когда собирают новую команду разработчиков, которые не сотрудничали друг с другом, стратегия ветвления — это одно из первых, что нужно решить. И будут люди, которые будут с пеной у рта доказывать, что одна стратегия лучше другой. Поэтому я хочу донести до вас информацию о том, какими вообще они бывают.

А нужны ли стратегии ветвления?

А вот нужны, и еще как нужны. Потому что если не договориться о чем-то в команде, получится, что каждый будет делать, что хочет:

• работать в той ветке, в которой он хочет;
• смердживать в другие ветки, в которые он хочет;
• удалять какие-то ветки;
• создавать новые;
• и так —каждый из членов команды в неуправляемом потоке.

Поэтому ниже приведу три стратегии. Поехали!

GitHub Flow стратегия

Стратегия ветвления, как бы это ни было странно, предпочитаемая в GitHub :) К ней прилагается набор правил, которым нужно следовать:

1. Код в master ветке должен быть не поломанным и готовым к развертыванию в любое время (то есть нельзя туда положить код, который помешает собрать проект и развернуть его на сервере).
2. Когда планируется работа над новой функциональностью, необходимо создать новую ветку (feature ветку) на основе master ветки и дать ей понятное имя. Коммитить свой код локально и регулярно пушить свои изменения на эту же ветку в удаленный репозиторий.
3. Открыть Pull-Request (что такое pull-request, можно почитать здесь), когда есть четкое ощущение, что работа готова и может быть смерджена в master ветку (или если уверенности нет, но хочется получить отзывы о проделанной работе).
4. После того, как новую фичу в пул-реквесте заапрувили, ее можно смерджить в master ветку.
5. Когда изменения смерджены в master ветку, их нужно развернуть на сервере немедленно.

По GitHub Flow получается, что прежде чем начать работу над чем-то новым, будь то исправление или новая фича, нужно создать новую ветку на основе master’а и дать ей подходящее имя. Далее, начинается работа над реализацией. Нужно постоянно отправлять коммиты на удаленный сервер с тем же именем. Когда приходит понимание, что все готово, нужно создать пул-реквест в master ветку. Потом хотя бы один, а лучше — два человека должны посмотреть этот код и нажать Approve. Обычно обязательно должен посмотреть тимлид проекта и кто-то еще, и тогда уже можно завершать пул-реквест. GitHub Flow еще известен тем, что драйвит Continuous Delivery(CD) на проекте. Потому что когда изменения заходят в master ветку, они должны сразу же быть развернуты на сервере.

GitFlow стратегия

Предыдущая стратегия (GitHub Flow) была по сути не очень сложной. Есть два типа веток: master и фиче ветки. А вот GitFlow уже серьёзнее. Как минимум из картинки выше вы это можете понять) Итак, как работает эта стратегия? В целом GitFlow состоит из двух постоянных веток и нескольких типов временных веток (В контексте GitHub Flow, master ветка — постоянная, а другие — временные). Постоянные ветки:

• master: эту ветку просто так никто не должен трогать/ничего не пушить туда. В этой стратегии master отображает последнюю стабильную версию, которую используют в продакшене (то есть на реальном сервере);
• development — это ветка для разработки. Потенциально она может быть нестабильная.

Разработка ведется при помощи трех вспомогательных временных веток:

1. Фиче ветки (feature branches) — для разработки новой функциональности.
2. Релизные ветки (release branches) — для подготовки выпуска новой версии проекта.
3. Хотфикс ветки (hotfix branches) — быстрое решение дефекта, который нашли уже реальные пользователи на реальном сервере.

Фиче ветки (feature branches)

Фиче ветки создаются разработчиками для нового функционала. Они всегда должны создаваться на основе development ветки. После завершения работы над новой функциональностью, нужно создать пул-реквест в development ветку. Понятно, что в больших командах одновременно может быть больше одной фиче ветки. Еще раз обратите внимание на картинку в начале описания стратегии GitFlow.

Релизные ветки (release branches)

Когда необходимое количество новых фич подготовлено в development ветке, можно подготовиться к выпуску новой версии продукта. В этом нам поможет релизная ветка. которая создается на основе development ветки. В ходе работы с релизной веткой нужно найти и починить все дефекты. Все новые изменения, которые требуются для стабилизации релизной ветки, нужно также смерджить обратно в development. Делается это для того, чтобы стабилизировать и development ветку. Когда тестировщики скажут, что ветка достаточно стабильная для нового релиза, ее смердживают в master ветку. Далее на этом коммите создается метка (tag: подробнее можно почитать об этом здесь), которой присваивается номер версии. Как пример, можно посмотреть на картинку в начале стратегии. Так вот, там Tag 1.0 — это как раз метка, которая указывает на версию 1.0 проекта. И последнее — это хотфикс ветки.

Хотфикс ветки (Hotfix branches)

Хотфикс ветки также предназначены для релиза новой версии в master. Только разница в том, что этот релиз не планируется. Бывают ситуации, когда дефекты доходят до релиза и уже обнаруживаются в работе. Например, iOS: как только выпустят новую версию, так сразу тебе куча обновлений с фиксами дефектов, которые обнаруживаются после релиза. В связи с этим нужно быстро пофиксить этот дефект и выпустить новую версию. На нашей картинке это соответствует версии 1.0.1. Идея заключается в том, что работа над новыми функциональностями может не останавливаться в моменты, когда нужно починить дефект на реальном сервере (как у нас говорят, “на проде”: опять калька с английского слова production). Хотфикс ветка должна создаваться от master ветки, так как она отображает состояние, которое работает в проде. Как только решение дефекта готово, смердживается в master, создается новая метка. Так же, как и подготовка релизной ветки, хотфикс ветка должна смерджить свое решение в development ветку.

The Forking Workflow стратегия

В рамках Forking Workflow стратегии разработка ведется так, что есть два репозитория:

1. Оригинальный репозиторий, в который будут смердживаться все изменения.
2. Форк репозиторий (это копия оригинального репозитория во владении другого разработчика, который хочет внести изменения в оригинальный).

Пока звучит как-то странно, да? Тем, кто уже сталкивался с open-source разработкой, этот подход уже знаком. Такая стратегия дает следующее премущество: разработка может вестись в форк-репозитории и без предоставления прав на совместную разработку в оригинальном. Разумеется, что владелец оригинального репозитория вправе отклонить предлагаемые изменения. Или согласиться и смерджить их. Это удобно и владельцу оригинального репозитория, и разработчику, который хочет поучаствовать в создании какого-то продукта. Например можно предложить изменения в ядро линукса. Если Линус решит, что они имеют смысл, изменения будут добавлены (!!!).

Пример The Forking Workflow

The Forking Flow применяется на GitHub’e в момент, когда есть какая-то библиотека, которую хочется использовать. В ней есть дефект, который мешает использовать ее полноценно. Допустим, вы погрузились достаточно в проблему и знаете решение. При помощи The Forking Workflow стратегии можно решить эту задачу без предоставления прав для работы в оригинальном репозитории библиотеки. Чтобы начать работу, нужно выбрать какой-то репозиторий, например, ядро Spring Framework, Находим в верхнем правом углу кнопку Fork и нажимаем ее: Это займет некоторое время, после чего появится копия этого оригинального репозитория в личном аккаунте, в котором будет указано, что она является форком: Далее вы можете работать с этим репозиторием в обычном режиме, добавлять изменения в master ветку и когда все будет готово — создать Pull-Request в оригинальный репозиторий. Для этого нужно нажать кнопку New Pull request:

Какую стратегию выбрать

Гит — это гибкий и мощный инструмент, который позволяет работать, используя широкий спектр процессов и стратегий. Но чем больше выбор, тем сложнее решить, какую именно стратегию сейчас выбрать. Ясно, что нет однозначного ответа для всех. Все зависит от ситуации. Тем не менее, есть несколько рекомендаций, которые могут помочь в этом:

1. Сперва лучше выбирать самую простую стратегию. Переходить к более сложным стратегиям только тогда, когда это нужно.
2. Рассматривать стратегии, в которых как можно меньше типов веток для разработчиков.
3. Посмотреть на плюсы и минусы разных стратегий и, в соответствии с проектом, выбрать нужную.

Это все, что я хотел рассказать по поводу стратегии ветвления в гите. Спасибо за внимание :) Подписывайтесь на мой гитхаб аккаунт, я там часто выкладываю свои наработки в разных технологиях и инструментах, которые использую в работе

Полезные ссылки

• GitHub flow: the best way to use Git and GitHub
• Pull request'ы на GitHub или Как мне внести изменения в чужой проект
• GitHub: About Pull-Requests
• Continuous Integration, Delivery, and Deployment Differentiated
• Основы Гит: работа с метками
• Хабр: Удачная модель ветвления для Git