06‐gitflow - xzima/gradle-semantic-release-example GitHub Wiki

Как организовать структуру веток в repo посредством gitflow(в моей интерпретации)?

GitFlow — это определенная надстройка над моделью ветвления Git, которая включает в себя использование feature веток и несколько основных веток

Основные концепции

Суть концепции заключается в том что в repo содержатся:

  • несколько веток с бесконечным сроком жизни -- 'бессмертные'
  • специализированные ветки, предназначенные для внесения изменений и переноса изменений между 'бессмертными' ветками

Далее все они будут расписаны подробнее.

master(главная ветка)

master - 'бессмертная' ветка, в которой находится стабильно работающий код с production версией кода.

Каждое изменение в master допускает создание stable(стабильной) версии релиза и требует merge(no-ff) в develop.

  • бесконечный жизненный цикл: ДА
    • ветка синхронизации: develop merge(no-ff)
  • соглашение об именовании: master
  • прямой push: НЕ хорошо
  • содержит release: stable

develop(ветка разработки)

develop - 'бессмертная' ветка, в которой находится последние изменения с nightly версией кода.

develop будет использоваться как активная ветка разработки. В develop будут тестироваться новые feature. Через develop будут пропускаться все изменения перед тем как они попадут в master.

Каждое изменение в develop допускает создание snapshot(нестабильной) версии релиза.

В некоторых случаях допускается merge(no-ff) из develop в master, однако предпочтительно это делать через ветку rc.

  • бесконечный жизненный цикл: ДА
    • ветка синхронизации: нет
  • соглашение об именовании: develop
  • прямой push: НЕ хорошо
  • содержит release: snapshot

rc(release candidate)

rc - ветка, в которой находится изменения взятые из develop для доставки в master.

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

  • исправление багов
  • создание документации
  • решение других задач, связанных с релизом

Каждое изменение в ветке rc допускает создание rc(предварительной) версии релиза.

Когда подготовка к поставке завершается, ветка rc merge(no-ff) в master.

  • бесконечный жизненный цикл: НЕТ
    • должна быть создана из: develop
    • должна быть merged в: master
    • допустимая стратегия слияния PR: merge(no-ff)
  • соглашение об именовании: rc/alpha/beta
  • прямой push: НЕ хорошо
  • содержит release: alpha/beta/release-candidate

feature(feature branch)

feature - ветка, которая предназначена для внесения изменений, связанных с задачами на добавление новых функциональностей или внесения исправлений.

Для каждой задачи следует создавать отдельную ветку feature. Для объединения feature с develop следует создать PR.

  • бесконечный жизненный цикл: НЕТ
    • должна быть создана из: develop
    • должна быть merged в: develop
    • допустимая стратегия слияния PR: squash | rebase
  • соглашение об именовании:
    • feature/i{ID}
    • bugfix/i{ID}
  • прямой push: да
  • содержит release: нет

hotfix(stable version fix)

hotfix - ветка, которая предназначена для внесения исправлений в production окружение.

hotfix используется в тех случаях когда в ветке develop уже есть новые функции, что не позволяет провести исправления через rc. Для каждого исправления следует создавать отдельную ветку hotfix. Для объединения hotfix с master следует создать PR.

  • бесконечный жизненный цикл: НЕТ
    • должна быть создана из: master
    • должна быть merged в: master
    • допустимая стратегия слияния PR: squash | rebase
  • соглашение об именовании: hotfix/i{ID}
  • прямой push: да
  • содержит release: нет

Источники