Основной репозиторий всегда будет содержать две постоянные ветки:

• master
• stable

Основной следует считать origin/master она будет веткой, где исходный код HEAD всегда отражает состояние с последними внесенными изменениями для следующего релиза. Как разработчик, вы будете создавать ветки и сливать(merge) их в ветку master.

origin/stable - Считается тем кодом, который развернут в продакшене на данный момент. В повседневной разработке с веткой stable вы не должны взаимодействовать.

Когда исходный код в ветке master стабилен и был развернут, ветка master будет слита(merge) в ветку stable и помечена номером релиза. Как это делается подробно будет обсуждено позже.

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

Различные типы веток, которые мы можем использовать:

• Feature ветки
• Bug ветки
• Hotfix ветки

Каждая из этих веток имеет конкретное назначение и подчиняется строгим правилам относительно того, от каких веток они могут исходить и в какие ветки должны сливаться. Каждая ветка и её использование объяснены ниже.

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

В течение жизненного цикла разработки функции тимлид должен следить за веткой master (с помощью сетевого инструмента или инструмента веток в GitHub), чтобы видеть, были ли коммиты с момента создания ветки Feature. Все изменения в master должны быть слиты в ветку Feature перед слиянием обратно в master; это можно сделать в разное время во время проекта или в конце, но время на разрешение конфликтов при слиянии должно быть учтено.

<tbd number> представляет проект, к которому будет привязываться управление проектом.

• Должна создаваться от: master
• Должна сливаться обратно в: master
• Правила именования веток: feature-<tbd number>

Если ветка ещё не существует (узнайте у тимлида), создайте ветку локально, а затем отправьте её в GitHub. Ветка Feature обычно является "публичной" или "публичной" в рамках команды. То есть, разработка никогда не должна существовать только в локальной ветке одного разработчика.

$ git checkout -b feature-id master                 // создаёт локальную ветку для новой функции
$ git push origin feature-id                        // делает новую функцию доступной удалённо

Периодически изменения, внесённые в master (если есть), должны быть слиты обратно в вашу ветку Feature.

$ git merge master                                  // сливает изменения из master в ветку Feature

Когда разработка функции завершена, тимлид (или другой ответственный) должен слиять ветку в master и затем убедиться, что удалённая ветка удалена.

$ git checkout master                               // переключиться на ветку master  
$ git merge --no-ff feature-id                      // гарантирует создание объекта коммита при слиянии
$ git push origin master                            // отправить изменения слияния
$ git push origin :feature-id                       // удалить удалённую ветку

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

Хотя вероятность меньше, в течение жизненного цикла разработки ошибки тимлид должен следить за веткой master (с помощью сетевого инструмента или инструмента веток в GitHub), чтобы видеть, были ли коммиты с момента создания ветки Bug. Все изменения в master должны быть слиты в ветку Bug перед слиянием обратно в master; это можно сделать в разное время во время проекта или в конце, но время на разрешение конфликтов при слиянии должно быть учтено.

<tbd number> представляет проект Basecamp, к которому будет привязываться управление проектом.

• Должна создаваться от: master
• Должна сливаться обратно в: master
• Правила именования веток: bug-<tbd number>

Если ветка ещё не существует (узнайте у тимлида), создайте ветку локально, а затем отправьте её в GitHub. Ветка Bug всегда должна быть "публичной" или "публичной" в рамках команды. То есть, разработка никогда не должна существовать только в локальной ветке одного разработчика.

$ git checkout -b bug-id master                     // создаёт локальную ветку для новой ошибки
$ git push origin bug-id                            // делает новую ошибку доступной удалённо

Периодически изменения, внесённые в master (если есть), должны быть слиты обратно в вашу ветку Bug.

$ git merge master                                  // сливает изменения из master в ветку Bug

Когда разработка ошибки завершена, [Тимлид] должен слиять ветку и изменения в master и затем убедиться, что удалённая ветка удалена.

$ git checkout master                               // переключиться на ветку master  
$ git merge --no-ff bug-id                          // гарантирует создание объекта коммита при слиянии
$ git push origin master                            // отправить изменения слияния
$ git push origin :bug-id                           // удалить удалённую ветку

Ветка Hotfix создаётся из необходимости немедленно реагировать на нежелательное состояние живой продакшн-версии. Кроме того, из-за срочности, ветка Hotfix не обязана быть слита во время планового деплоймента. Из-за этих требований ветка Hotfix всегда создаётся от помеченной ветки stable. Это делается по двум причинам:

• Разработка в ветке master может продолжаться, пока решается Hotfix.
• Помеченная ветка stable всё ещё представляет то, что находится в продакшене. В момент, когда Hotfix необходим, могли быть сделаны несколько коммитов в master, которые больше не будут представлять продакшн.

представляет проект Basecamp, к которому будет привязываться управление проектом.

• Должна создаваться от: помеченной ветки stable
• Должна сливаться обратно в: master и stable
• Правила именования веток: hotfix-<tbd number>

Если ветка ещё не существует (узнайте у тимлида), создайте ветку локально, а затем отправьте её в GitHub. Ветка Hotfix всегда должна быть "публичной". То есть, разработка никогда не должна существовать только в локальной ветке одного разработчика.

$ git checkout -b hotfix-id stable                  // создаёт локальную ветку для нового горячего исправления
$ git push origin hotfix-id                         // делает новое горячее исправление доступным удалённо

Когда разработка Hotfix завершена, [тимлид] должен слиять ветку и изменения в stable и затем обновить тег.

$ git checkout stable                               // переключиться на ветку stable
$ git merge --no-ff hotfix-id                       // гарантирует создание объекта коммита при слиянии
$ git tag -a <tag>                                  // помечает исправление
$ git push origin stable --tags                     // отправляет изменения тегов

Слияйте ветку с изменениями в master, чтобы не потерять Hotfix, а затем удалите удалённую ветку Hotfix.

$ git checkout master                               // переключиться на ветку master
$ git merge --no-ff hotfix-id                       // гарантирует создание объекта коммита при слиянии
$ git push origin master                            // отправить изменения слияния
$ git push origin :hotfix-id                        // удалить удалённую ветку

gitflow-model.src.key

• Стандарты и соглашения по коммитам Git/GitHub
• Успешная модель ветвления Git (основа этой модели потока) (основа)