Стратегии ветвления в Git — Примеры

Пример 1 — Ветка функции, прожившая три недели

Пока функцию не доделают, команда держит под неё отдельную ветку. Запись ниже относится к ветке, слитой в прошлом месяце. Скажите, чего стоила такая стратегия, и покажите ту же работу, но при коротких ветках.

feature/new-checkout   ответвлена 3 недели назад
main                   +41 коммит с точки ветвления
merge                  -> 27 конфликтующих файлов, два дня правок

Решение

день 1  ветка от main, коммит первого среза
день 1  слияние в main за флагом: newCheckout=false
день 2  снова ветка от main для следующего среза
выпуск  переключить флаг; ни события слияния, ни ветки стабилизации

Поверхность интеграции у коротких веток остаётся маленькой: два изменения встречаются на другой день после того, как каждое написали. При трёхнедельной ветке момент встречи отодвинулся бы на те же три недели. Незавершённую работу прячет флаг, поэтому main остаётся готовым к выпуску, а результат CI описывает нечто близкое к тому, что команда действительно строит. Платить придётся тем, что флаг нужно сопровождать и со временем убрать, — и это куда дешевле, чем вручную разрешать трёхнедельное расхождение.

Пример 2 — Стратегия, противоречащая процессу выпуска

Любой зелёный коммит команда разворачивает по нескольку раз в день. И всё же GitFlow здесь приняли — просто потому, что так было в прошлой компании. Через два месяца develop ушёл на три недели вперёд от main; разберите это расхождение и назовите стратегию, которая процессу выпуска действительно нужна.

main     ----o------------------o--->
              \                /
develop  ------o--o--o--o--o--o      3 недели вперёд
release                 o--o          единственный стабилизированный артефакт

Решение

main   ----o----o----o----o---->   всегда готов к выпуску
              \  /    \  /
               o       o           сливаются в течение дня

tag v1.4 на развёрнутом коммите; хотфикс от тега, слитый вперёд

Стратегию решает процесс выпуска, а не наоборот. Если развернуть можно любой коммит, стабилизировать ветке стабилизации нечего: ветка выпуска превращается в этап, который процесс пропускает, а develop существует лишь затем, чтобы main казался устаревшим. Trunk-based development моделирует такой процесс напрямую: развёрнутый коммит помечают тегом, а не замораживают. А отказаться нужно вот от чего: от смеси, о которой никто не договаривался, — здесь ветка выпуска остаётся единственным артефактом, который кто-либо тестирует, и это ровно то расхождение, которое стратегия и должна была предотвратить.