Скотт Чакон - Pro Git

Рисунок 20. История с несколькими тематическими ветками.

Рисунок 21. Слияние тематической ветки.

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

Если у вас очень важный проект, то возможно вам стоит использовать двухступенчатый цикл слияния. При таком сценарии у вас имеются две долгоживущие ветки master и develop, где в master сливаются только очень стабильные изменения, а все новые доработки интегрируются в ветку develop. Обе ветки регулярно отправляются в публичный репозиторий. Каждый раз, когда новая тематческая ветка готова к слиянию (Перед слиянием тематической ветки.), вы сливаете её в develop (После слияния тематической ветки.); затем, когда вы выпускаете релиз, ветка master смещается на стабильное состояние ветки develop (После релиза проекта.).

Рисунок 22. Перед слиянием тематической ветки.

Рисунок 23. После слияния тематической ветки.

Рисунок 24. После релиза проекта.

Таким образом, люди могут клонировать репозиторий вашего проекта и использовать ветку master для сборки последнего стабильного состояния и получения актуальных изменений или использовать ветку develop, которая содержит самые последние изменения. Вы также можете продолжить эту концепцию, имея ветку интеграции, в которой объединяется вся работа. После того, как кодовая база указанной ветки стабильна и пройдены все тесты, она сливается в ветку develop, а после того, как стабильность слитых изменений доказана, вы перемещаете состояние ветки master на стабильное.

В проекте Git присутствуют четыре долгоживущие ветки: master, next, pu (предложенные обновления) для новой работы и maint для поддержания бэкпортов. Новая проделанная работа предоставляется участниками в тематические ветки основного репозитория по принципу, описанному ранее (смотри Управление сложным набором паралельно разрабатываемых тематических веток.). В этот момент производится проверка этих веток на безопасность и готовность или необходимость доработки. Если это безопасно, изменения сливаются с веткой next, для того, чтобы остальные участники проекта могли проверить интегрированные изменения.

Рисунок 25. Управление сложным набором паралельно разрабатываемых тематических веток.

Если тематические ветки требуют доработки, то они сливаются в ветку pu. Когда тематические ветки признаются полностью стабильными, то снова сливаются в master и перестраиваются на основании изменений, находящихся в next, но ещё не попавших в master. Это означает, что master практически всегда двигается только вперед, next время от времени перебазируется, а pu перебазируется часто:

Рисунок 26. Слияние тематических веток в долгоживущие ветки интеграции.

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

Некоторые сопровождающие предпочитают перебазировать или выборочно применять (cherry-pick) изменения относительно ветки master вместо слияния, что позволяет поддерживать историю проекта в линейном виде. Когда проделанная работа из тематической ветки готова к интеграции, вы переходите на эту ветку и перебазируете её относительно ветки master (или develop и т.д.). Если конфликты отсутствуют, то вы можете просто сдвинуть состояние ветки master, что обеспечивает линейность истории проекта.

Другим способом перемещения предлагаемых изменений в из одной ветки в другую является их выборочное применение (cherry-pick). Выборочное применение в Git похоже на перебазирование для одного коммита. В таком случае формируется патч для выбранного коммита и применяется к текущей ветке. Это полезно, когда в тематической ветке присутствует несколько коммитов, а выхотите применить только один из них, или в тематической ветке только один коммит и выхотите его применить вместо использования перебазирования. Например, предположим, что ваш проект выглядит следующим образом:

Рисунок 27. Пример истории до выборочного слияния.

Для применения коммита e43a6 к ветке master выполните команду:

$git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf

Finished one cherry-pick.

[master]: created a0a41a9: "More friendly message when locking the index fails."

3 files changed, 17 insertions(+), 3 deletions(-)

Это действие применит изменения, содержащиеся в коммите e43a6, но будет сформирован новый коммит с другим значением SHA-1. После этого история будет выглядеть так:

Рисунок 28. История после выборочного применения коммита из тематической ветки.

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

Если вы часто производите перебазирование и слияние или поддерживаете догоживущие тематические ветки, то в Git есть специальная возможность под названием “rerere”, призванная вам помочь.

Её название расшифровывается как “переиспользование записанного разрешения”, а применяется для ускорения ручного разрешения конфликтов. Когда эта опция включена, Git будет сохранять набор образов до и после успешного слияния, а так же разрешать конфликты самостоятельно, если аналогичные конфликты уже были разрешены ранее.