Регламент работы с Git - AlexMisha/callcenter GitHub Wiki

Коммиты

Стиль подписи коммита хорошо описан тут - https://chris.beams.io/posts/git-commit/

Git flow

Подход хорошо описан здесь - https://habr.com/ru/post/106912/

Основные ветки:

  • master - стабильный production-ready код. Коммит напрямую запрещен
  • develop - основная ветка разработки, от нее отделяются feature-* и release-* ветки
  • feature-* - ветвь для реализации какой-либо фичи. Например, feature-api
  • release-* - создается от develop, когда изменения становятся стабильны. Содержит номер версии, например, release-1.0. Сопровождается созданием тега версии.
  • hotfix-* - для срочных изменений в master

Объяснение git flow на примере задачи https://trello.com/c/tFkV4fJF/21-создать-базу-данных-и-слой-данных

При разработке создается ветвь от develop - feature-api. Все работы по задаче проводятся в этой ветке (при необходимости можно создавать дочерние от созданной).

После реализации создается pull request с target branch - develop и передается на ревью. В описании задачи необходимо оставить ссылку на PR. При наличии замечания ревьюера исправляются в той же ветке.

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

После успешного прохождения тестирования pull request принимается, и изменения оказываются в ветке develop.

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

После финального тестирования создается ветка release-version, помечается тегом версии и мержится в master


Итого цикл задачи

Создание ветки feature-* -> Создание PR (pull request) -> Ревью -> Тестирование -> merge PR.