Когда все изменения в текущей тематической ветке готовы к интеграции с основной веткой, возникает вопрос как это сделать. Кроме этого, какой рабочий процесс вы хотите использовать при сопровождении вашего проекта? У вас несколько вариантов, рассмотрите некоторые из них.
Схемы слияния
В простом рабочем процессе проделанная работа просто сливается в ветку master.
При таком сценарии у вас есть ветка master, которая содержит стабильный код. Когда работа в тематической ветке завершена и вы проверили работу, вы вливаете ее в ветку master и удаляете тематическую ветку. Затем процесс повторяется.
Например, в репозитории присутствуют две тематические ветки feature/issue-11 и feature/issue-53, работа в которых выполнена и проверена.
Сначала вы вливаете в master ветку feature/issue-11, а затем feature/issue-53. В результате ваш репозиторий будет выглядеть следующим образом.
Это, пожалуй, простейший рабочий процесс и его использование проблематично в больших или более стабильных проектах, где вы должны быть более осторожны с предоставленными изменениями.
Если у вас очень важный проект, то возможно вам стоит использовать двухступенчатый цикл слияния. При таком сценарии у вас имеются две долгоживущие ветки master и develop, где в master вливаются только очень стабильные изменения, а все новые доработки интегрируются в ветку develop. Обе ветки регулярно отправляются в публичный репозиторий.
Например, новая тематическая ветка feature/issue-53 готова к слиянию.
Вы вливаете ее в develop.
После того, как вы выпускаете релиз, ветка master смещается на стабильное состояние ветки develop.
Таким образом, люди могут клонировать репозиторий вашего проекта и использовать ветку master для сборки последнего стабильного состояния и получения актуальных изменений или использовать ветку develop, которая содержит самые последние изменения.
Вы также можете продолжить эту концепцию, имея интеграционную ветку integrate, в которой объединяется вся работа. После того, как кодовая база указанной ветки стабильна и пройдены все тесты, она вливается в ветку develop, а после того, как стабильность слитых изменений доказана, вы перемещаете состояние ветки master на стабильное.
Схема с большим количеством слияний
Например, в проекте Git присутствуют три долгоживущие ветки: master, next, pu?(proposed updates). Предложенные участниками проекта наработки накапливаются в тематических ветках основного репозитория по ранее описанному принципу: feature/issue-11, feature/issue-53, feature/issue-771 и feature/issue-95.
На этом этапе производится оценка содержимого тематических веток, чтобы определить, работают ли предложенные фрагменты так, как положено, или им требуется доработка.
Если все в порядке, тематические ветки вливаются в ветку next, которая отправляется на сервер, чтобы у каждого была возможность опробовать результат интеграции. Если содержимое тематических веток требует доработки, они вливаются в ветку pu. Когда выясняется, что предложенный код полностью стабилен, он вливается в ветку master.
Затем ветки next и pu перестраиваются на основании master. Это означает, что master практически всегда двигается только вперед, next время от времени перебазируется, а pu перебазируется еще чаще.
После того, как тематическая ветка окончательно слита в master, она удаляется из репозитория.
Репозиторий также содержит ветку maint, которая ответвляется от последнего релиза для предоставления патчей, если требуется поддержка обратной совместимости. Таким образом, после клонирования проекта у вас будет четыре ветки, дающие возможность перейти на разные стадии его разработки, в зависимости от того, на сколько передовым вы хотите быть или как вы собираетесь участвовать в проекте. Вместе с этим, рабочий процесс структурирован, что помогает сопровождающему проекта проверять поступающий код.
Рабочий процесс проекта Git специфицирован. Для полного понимания процесса обратитесь к Git Maintainer’s guide.
Схема с перебазированием и отбором
Некоторые менеджеры вместо слияния предпочитают перебазировать изменения на ветку master или выполнять операцию cherry-pick. Это позволяет поддерживать историю проекта в линейном виде.
Когда проделанная работа из тематической ветки готова к интеграции, вы переходите на эту ветку и перебазируете ее на ветку master (или develop и т. д.). Если конфликты отсутствуют, то вы можете просто сдвинуть состояние ветки master, что обеспечивает линейность истории проекта.
Другим способом переместить предлагаемые изменений из одной ветки в другую является cherry-pick. Это похоже на перебазирование одного коммита. В этом случае формируется патч для выбранного коммита и применяется к текущей ветке. Cherry-pick полезен, когда в тематической ветке присутствует несколько коммитов, а вы хотите взять только один из них, или в тематической ветке только один коммит и вы предпочитаете использовать cherry-pick вместо перебазирования.
Например, ваш проект выглядит так.
В панели История вы позиционируетесь на коммите 3 и нажимаете Cherry-Pick.... Это действие применит изменения, содержащиеся в коммите 3, но будет сформирован новый коммит с другим значением SHA-1. После этого история будет выглядеть так.
Теперь ветку feature/issue-53 можно удалить, отбросив тем самым коммиты, которые вы не собираетесь включать в проект.
По материалам книги Pro Git (авторы Scott Chacon и Ben Straub, издательство Apress). Книга распространяется по лицензии Creative Commons Attribution Non Commercial Share Alike 3.0 license.