Вариант git-flow, применяемый нашей командой.
Switch branches/tags
Nothing to show
Clone or download
igor-shevchenko Merge pull request #1 from antidasoftware/gitgraphjs-image
Новая картинка для воркфлоу
Latest commit e191c09 Apr 26, 2017

README.md

Здесь описана схема работы с системой контроля версий, которую мы применяем в Antida software. Эти правила позволяют обеспечить нам:

  • Частые релизы (каждый день).
  • Возможность ручного и автоматического тестирования всех изменений.
  • Простой процесс подготовки релиза.

Управление задачами

  • Для управления задачами мы используем Agile-доску, например, YouTrack или Trello.
  • У каждой задачи есть номер. Номера задач используются в описаниях коммитов и названиях фича-бранчей.

Долгоживущие ветки

  • Две ветки существуют постоянно: master и dev (или develop).
  • master содержит стабильный протестированный код. Код в этой ветке всегда готов к деплою на продакшн.
  • dev содержит код, готовый для тестирования.
  • Нельзя делать коммиты напрямую в dev и master, только в фича-бранчи.

Фича-бранчи (feature branches)

  • На каждую задачу создается отдельная ветка. Вся работа над задачей ведется в этой ветке.
  • Формат имени ветки: номер задачи (без решетки) и одно или несколько английских слов, описывающих задачу, через дефисы. Пример: 350-avatar-min-size.
  • Фича-бранчи ответвляются от master. Это важно, потому что код в dev может быть еще не протестированным и содержать баги. Этим наш подход отличается от GitFlow, в котором ветки создаются из develop.
  • Когда работа над задачей завершена, ветка мёржится в dev, и новая версия кода заливается на тестовый сервер.
  • Если после тестирования понадобилось что-то доделать по этой задаче, то изменения делаются в той же самой ветке, а потом опять мёржатся в dev. Нельзя делать изменения сразу в dev, потому что тогда они не попадут в master.
  • Когда задача готова и протестирована, фича-бранч можно смёржить в master для релиза.
  • Важно не забывать пушить ветку в общий репозиторий, иначе в релиз попадет недоделанная задача.

Коммиты

  • В описании коммита должен содержаться номер задачи, к которой он относится.
  • Перед номером задачи должна быть решетка — в таком формате некоторые системы смогут понять, что это номер задачи (например, гитхаб сделает номер ссылкой на соответствующий Issue).
  • Пример описания коммита: #84 поменял фоновую фотографию на форме обратной связи.

Зависимости между задачами

  • Часто возникает ситуация, когда задачи зависят друг от друга. Пример: на доске есть задачи #119 «Добавить отображение аватара в профиле пользователя» и #125 «Сделать страницу профиля адаптивной». Предполагается, что для аватара тоже нужно настроить адаптивность.
  • В этом случае одна из веток должна стать зависимой от другой. Можно замёржить ветку 119 в ветку 125 и реализовать отображение аватара в адаптивной версии в ветке 125. Можно и наоборот: влить ветку 125 в 119.
  • В качестве зависимой можно выбрать любую из двух веток. Но лучше, чтобы ветка, работа по которой будет завершена раньше, оставалсь независимой. Если задача #119 будет сделана через 1 день, а задача #125 через неделю, то надо вливать 119 в 125. Если сделать наоборот (чтобы 119 зависела от 125) придется ждать окончания работы над 125, чтобы замёржить 119 в мастер.
  • В карточке задачи на доске должны быть упомянуты зависимости. Если ветка 119 была замёржена в 125, в карточке #125 нужно оставить комментарий о том, что она зависит от #119. Иначе задача #125 может быть включена в релиз раньше, чем будет готова #119.
  • Если две ветки логически не зависят друг от друга, но при этом их нужно нетривиально мёржить, можно таким же образом сделать одну из них зависимой. Тогда при сливании в master не придется повторять мёрж еще раз. Например, в двух ветках вносятся изменения в разные поля одной модели, и нужно определить правильный порядок для миграций.

Релиз

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

Исключения

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

Пример

Пример

Другие модели ветвления