Регламент работы с 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-apirelease-*- создается от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.