git flow
Best Git Flow

В поисках лучшего Git Flow

16 марта, 2017
1 минута чтения

Если контент не отображается, включите VPN.

В больших проектах для распределенных команд выбор инструментария для совместной работы над кодовой базой заканчивается гитом. Гит — очень мощный тулчейн, однако его команды запутаны и неочевидны. И хотя все команды гита можно выучить прочитав книгу ProGit, но выбрать подходящий git flow для проекта требует долгой практики работы с разными проектами. Для распределенных команд численностью от шести человек я рекомендую воспользоваться следующим способом.

Best Git Flow

Создайте stage ветку, которая будет содержать все коммиты, включая те от которых придется отказаться. Для удаления комитов из stage ветки я рекомендую воспользоваться интерактивным ребейзом или командой drop из IDEA.

Делайте свои фича ветки, ветвясь от stage. Периодически подливая правки из stage ветки, посредством rebase. Заливка фича веток на stage должна делаться командой merge с no-fast-forward.

После выполнения майелстоуна или спринта все фичи должны отдаваться на тестирование в ветку RC посредством squash коммитов. Для этого используйте версионирование через теги или новый комит с указанием версии. Удаление неисправных версий делается через удаление комитов или тегов.

После получения апрува от тестирования, выбранная версия отправляется на master посредством squash комита.

Удаление веток

# Локальное удаление ветки
git branch -D branch1

# Удаление ветки в репозитории
git push :branch1

# Удалить смерженные ветки в репозитории
git push --all --prune

# Локальное удаление смерженных веток
git fetch origin --prune

Переименование локальной ветки

git branch -m <BRANCH_BEFORE> <BRANCH_AFTER>

Отображение веток

# удобное отображение лога в виде графа
git log --color --graph --pretty=format:'%Cred%h%Creset 
-%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

# показ смеренных веток
git branch --merged 

# показ всех тегов
git tag --list

Способы доставки коммитов

# cherry-pick - используется для патчей. Патч делается в ветку stage/rc от feature ветки с использованием первоначального хэша и исправлением конфликтов
git cherry-pick <COMMIT_HASH>

# rebase - используется для локальной ветки
git pull --rebase origin <BRANCH>

# merge no fast forward - используется для stage ветки
git merge --no-ff <BRANCH>

# squash - используется для rc ветки
git merge --squash <BRANCH>

# tag - используется для формирование релизных тегов
git tag -a <VERSION>

Денис Сергеевич Басковский

Философ, изобретатель и поэт.

Подписаться
Уведомить о
guest
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Gitlab Version
Предыдущая статья

Пример получения версии GitLab из NodeJS

js cases
Следующая статья

Преобразуем underscore_case в camelCase и в camel-Case-To-Dash