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

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

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

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

• На каждую задачу создается отдельная ветка. Вся работа над задачей ведется в этой ветке.
• Формат имени ветки: номер задачи (без решетки) и одно или несколько английских слов, описывающих задачу, через дефисы. Пример: 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, которая сразу деплоится на тестовый сервер. Переход на использование фича-бранчей происходит при подготовке первого релиза.

• Описание похожей модели ветвления на Хабре.
• Описание разных workflow в блоге End Point.