Git flow | GitHub flow | GitLab Flow
Если не устанавливать никаких правил работы с ветками, в репозитории начинает расти энтропия:
- Появляется много долгоживущих веток,
- Вносимые изменения оказываются размазанными по разным веткам,
- Непонятно, откуда начинать разработку новой фичи или откуда разворачивать код на production.
Git Flow
Предполагает наличие основной ветки master, ветки для накопленных изменений develop, а также отдельных веток для фич, релизов и хотфиксов
Разрабатываемые изменения мержатся в develop, оттуда в релизные ветки, и в итоге попадают в master
Нередко разработчики по ошибке мержат какие-то изменения только в master, забывая про develop. А большинство графических интерфейсов к git по умолчанию считают основной веткой именно master, поэтому в них приходится каждый раз что-то переключать или настраивать
Появляется лишняя сложность из-за веток релизов и хотфиксов. Большинство команд, особенно небольших, может легко обойтись без них
Поэтому это избыточно и не удобно
GitHub Flow
Самая простая модель
Здесь есть только master и feature-ветки
Мерджить в мастер и часто деплоиться - круто, но остается много других вопросов
GitLab Flow
GitLab flow: ветка production
Здесь мы можем настроить автодеплой при любом изменении в ветке production
Мерджить в master можно когда угодно
А мерджить в production из master будем тогда когда нам удобно
GitLab flow: ветки для нескольких сред
Предположим, что у вас есть несколько сред: стейджинг (staging), пре-продакшен (pre-production) и продакшен (production). Код из master автоматически развёртывается на стейджинг. Как только вы готовы развернуть его на пре-продакшен, вы создаете мерж-реквест из master в pre-production. Соответственно, мерж из pre-production в production означает окончательный релиз. Такой процесс, когда все коммиты проходят через ветки в строго определенном порядке, гарантирует, что изменения прошли тестирование во всех средах
GitLab flow: релизные ветки
Это удобно при предоставлении ПО внешним клиентам. Здесь каждая минорная версия хранится в отдельной ветке
Следуйте правилу "upstream first": всегда, когда это возможно, сначала делайте мерж исправлений в master, и только оттуда — cherry-pick в релизную ветку. Благодаря этому правилу вы не забудете сделать cherry-pick исправлений в master и не встретите тот же самый баг в следующем релизе
No Comments