Модели ветвления git. Github flow

В современном мире разработки знание команд для работы с git не означает обязательный успех в командной разработке. В команде важно закрепить какой-либо способ работы с git: какая ветка является основной для разработки, когда необходимо производить слияние веток, какая из них является той, которая выгружается на рабочку, и т.д. Набор таких правил называется моделью ветвления (англ.: workflow). В зависимости от того, над каким проектом вы работаете, а также какую модель ветвления в git вы используете и определяется эффективность работы команды разработчиков.

Использование модели ветвления git – эта командная практика работы с репозиторием. Следование данной практике, удается добиться организованности в работе, минимального количества конфликтов в коде, а также определить подходящий для команды способ публикации изменений в проекте.

Существует несколько наиболее известных моделей ветвления git, которые подходят практически для любого случая. Если вы впервые слышите про модели ветвления, или хотели бы расширить свой кругозор – то этот цикл статей именно для вас. Однако, следует помнить, что любая модель ветвления - это не набор жестких правил. Всегда можно адаптировать модель под себя.

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

В данном цикле статей предполагается, что у читателя имеется базовый опыт работы с git, он ориентируется в терминах git: коммит, слияние, ветка, репозиторий, pull-request, fork. Также предполагается, что читатель умеет работать с git. Статьи преследуют цель показать суть той или иной модели ветвления, а не подробнейшее описание моделей.

Описание популярных моделей ветвления начнется с одной из самых простых – github flow.

Github flow

Хоть данная модель ветвления и названа в честь одноименного сервиса, однако, уверен, многие компании, а также отдельные программисты давно и с успехом ею пользуются. Это очень простая и, вместе с тем, эффективная модель ветвления.

Основная ветка master, которая содержит последний актуальный и наиболее стабильный код.

Нужна новая функциональность – fork’аем новую ветку от master, реализуем функциональность, вливаем в master через механизм pull-request.

Нужно исправить баг в master – fork’аем ветку от master, правим баг, вливаем в master через pull-request.

Все – в этом и состоит модель ветвления github. Примерно так в общем случае и выглядит использование данной модели ветвления:

По заверениям разработчика из github, в их команде насчитывается порядка 35 человек, и все они работают над их основным проектом – github. Так как же такая простая модель ветвления является для них подходящей? Ответ кроется в двух простых правилах, которым следуют разработчики github:

• Написал функционал – сделай pull-request в master. Добейся того, чтобы твой код понравился другим разработчикам. В командной разработке очень важно, чтобы твой код понимали еще и другие, именно поэтому так важно получить одобрение на внесение правок в master от коллег.


• Твой код одобрили другие разработчики – вливай функциональность в master и релизь код на рабочку. Таким образом достигается еще один очень важный эффект – на рабочке находится наиболее свежий код, который релизится очень часто. Не страшно даже, что на рабочке может появиться баг – он очень быстро обнаружится пользователями системы и очень быстро поправится разработчиками.

Итог

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

Ссылки

Оригинал статьи (англ., очень длинная)

Официальный гайд по github flow