Блог о программировании

Модели ветвления git. Tochka workflow

 12 марта 2018 г. 23:09

Сразу оговорка. Название tochka workflow является собирательным, поскольку именно в компании Точка впервые пришлось столкнуться с данной моделью ветвления.

Данная модель ветвления довольно популярна в больших компаниях, где каждый проект тесно связан с другими активно развивающимися проектами внутри этой самой компании. Tochka workflow очень похож на gitflow, но вместе с тем, эта модель ветвления решает известную проблему gitflow: если при подготовке релиза необходимо срочно отказаться от некоторой функциональности проекта, gitflow для этого просто не предусмотрен, такая ситуация может добавить головной боли команде. В tochka workflow такой проблемы нет. В связи с тем, что в статье часто будут проводиться параллели с gitflow, перед дальнейшем прочтением статьи, целесообразно ознакомиться с gitflow тем, кто не знаком с этой моделью ветвления. Описание gitflow доступно здесь.

В обеих моделях есть две основные ветки – master и develop. Точно также изначально от master-ветки fork’ается ветка develop.

tochka workflow. Develop-ветка

tochka workflow. Develop-ветка

Но если назначение ветки master одинаково – там хранятся все релизы проекта, то есть находится код, который всегда готов быть отправлен на рабочку. С develop-веткой все несколько иначе. В gitflow в develop-ветке ведется разработка, в tochka workflow ветка develop необходима для тестирования функциональности.

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

tochka workflow. Ветки с фичами

tochka workflow. Ветки с фичами

Фиксируем, feature-ветки fork’аются от master, а вливаются в develop. Код из develop-ветки выгружается на тестовый стенд, где его всячески тестируют.

Если обнаруживается ошибка в какой-то фиче, то она правится в ветке этой самой фичи. После чего опять вливают feature-ветку, в которой был исправлен баг, в develop-ветку.

tochka workflow. Исправлен баг в фиче

tochka workflow. Исправлен баг в фиче

Как уже было сказано, в develop попадают фичи для тестирования. В общем случае эти фичи не привязаны ни к какому релизу. Поэтому, для подготовки релиза в tochka workflow используется еще одна ветка – release.

tochka workflow. Создание release-ветка

tochka workflow. Создание release-ветка

Release-ветка также как и develop, fork’ается от master. В эту ветку вливаются только те фичи, которые должны попасть в релиз.

tochka workflow. Вливание фич в release-ветку

tochka workflow. Вливание фич в release-ветку

Таким образом, в release-ветке накапливаются все изменения предстоящего релиза. Теперь, когда все изменения собраны в release, самое время эту ветку вливать в master. Это также может делаться через pull-request для еще одной возможности проконтролировать вносимые изменения. Также можно заметить, что в release содержится код, который впоследствии попадет на рабочку, то есть этот код можно дополнительно протестировать. Далее в master выставляется тег с номером релиза, а код попадает на рабочку.

tochka workflow. Формирование первого релиза в master

tochka workflow. Формирование первого релиза в master

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

Итог

Показана еще одна жизнеспособная модель ветвления. Назначения основных веток:

  • Master – содержит все релизы проекта, код отсюда всегда готов попасть на рабочку;
  • Develop – содержит все разрабатываемые фичи проекта, здесь код тестируется;
  • Release – здесь собираются фичи, которые должны попасть в следующий релиз.

Поделиться статьей

Оставить комментарий