Статья базируется на замечательном труде Successfull branching model и является выжимкой из нее с добавлением некоторых пояснений и команд для работы с удаленным репозиторием. Далее я приведу карту взаимодействия бранчей, полное описание которой вы можете самостоятельно прочесть в упомянутой статье, и опишу все возникающие в процессе работы кейсы. При описании я буду употреблять терминологию исходной статьи, которая в оной же уже разъяснена, так что повторяться я не буду.
Важно: этот тип бранчей должен иметь префикс feature-
# перейдем в девел ветку git checkout devel # возьмем ее последнее состояние с сервера git pull # создадим feature бранч git checkout -b feature-myfeature
Если вам нужно работать с фича-бранчем совместно с другими разработчиками, есть смысл опубликовать его на сервер (в удаленный репозиторий):
git push origin feature-myfeature -u
После успешной работы по новой фиче вам следует слить ее в девел. Здесь у нас есть 2 варианта слияния: мы сливаем наш локальный бранч (работали с ним локально, на удаленный сервер не публиковали, либо уверены, что имеем локально последнюю и самую свежую версию) или же мы сливаем удаленный бранч (с ним работали другие разработчики или мы не уверены, что локально есть самая свежая версия и нам лениво это проверять).
Для первого случая локального бранча команды будут выглядеть так:
# Переходим в девел бранч git checkout devel # Сливаем локальный бранч git merge --no-ff feature-myfeature # удаляем локальный бранч git branch -d feature-myfeature # Публикуем новую версию devel на сервер git push origin devel
Для второго случая: мы сливаем удаленный бранч:
# Переходим в девел бранч git checkout devel # Сливаем локальный бранч git pull --no-ff origin feature-myfeature # удаляем локальный бранч (если есть) git branch -d feature-myfeature # Удаляем бранч с сервера git push origin :feature-myfeature # Публикуем новую версию devel на сервер git push origin devel
Внимание: release бранчи имеют префикс release-
# Переходим в девел и обновляем его git checkout devel git pull # Создаем релиз-бранч git checkout -b release-1.2 devel # Если надо, публикуем его на сервер git push origin release-1.2
Если работаем с локальным релиз-бранчем, т.е. не публиковали его на сервер
# Переходим в мастер, обновляем его git checkout master git pull # Сливаем релиз в мастер git merge --no-ff release-1.2 # Создаем таг git tag -a v1.2 -m 'коммент к тагу' # Публикуем мастер и таг на сервер git push origin master git push origin v1.2 # сливаем в девел git checkout devel git pull git merge --no-ff release-1.2 git push origin devel # Удаляем релиз-бранч git branch -d release-1.2
Если работаем с удаленным релиз-бранчем
# Переходим в мастер, обновляем его git checkout master git pull # Сливаем релиз в мастер git pull --no-ff origin release-1.2 # Создаем таг git tag -a v1.2 -m 'коммент к тагу' # Публикуем мастер и таг на сервер git push origin master git push origin v1.2 # сливаем в девел git checkout devel git pull git pull --no-ff origin release-1.2 git push origin devel # Удаляем локальный релиз-бранч (если есть) git branch -d release-1.2 # Удаляем релиз-бранч с сервера git push origin :release-1.2
В случае, если релиз-бранч не задался и было решено, что релиз мы делать не будем, то следует слить релиз-бранч с девелом и удалить его.
В случае локального релиз-бранча
# Переходим в девел и обновляем его git checkout devel git pull # Сливаем релиз-бранч в девел и публикуем последний git merge release-1.2 git push origin devel # Удаляем релиз-бранч git branch -d release-1.2
В случае работы с удаленным релиз-бранчем
# Переходим в девел и обновляем его git checkout devel git pull # Сливаем релиз-бранч в девел и публикуем последний git pull origin release-1.2 git push origin devel # Удаляем локальный релиз-бранч (если есть) git branch -d release-1.2 # Удаляем релиз-бранч с сервера git push origin :release-1.2
Важно: хотфикс-бранчи должны иметь префикс hotfix-
Именование хотфиксов не обязательно содержит номер версии, а может, например состоять из префикса и человекопонятного имени хотфикса.
# Хотфиксы начинаются из мастера git checkout master git pull git checkout -b hotfix-1.2.1
Если вы хотите, чтобы кто-то кроме вас мог принимать участие в работе над хотфиксом, вам следует опубликовать его на сервер:
git push origin hotfix-1.2.1
Когда работа над исправлениями закончена, нам следует слить хотфикс обратно в мастер, а кроме того, если в данный момент открыт релиз-бранч, то еще и в него, если же релиз-бранчей нету, то в девел.
Как и в предыдущих разделах, рассмотрим два варианта: с локальным хотфикс бранчем и с удавленным. В примерах будет описана ситуация, когда у нас нету текущих релиз-бранчей, поэтому мы будем сливать хотфикс с devel веткой. Если у вас есть текущий релиз-бранч, то вам надо будет подправить пару строк кода примеров под себя. Подразумевая то, что читатель все же хоть немного да знает гит, думаю трудностей такие правки у него не вызовут.
Слияние локального хотфикс-бранча:
# Слияние с мастером git checkout master git pull git merge --no-ff hotfix-1.2.1 git tag -a v1.2.1 -m 'Hotfix applied comment' git push origin master git push origin v1.2.1 # Слияние с девелом (эту секцию надо править, если у вас есть релиз-бранч) git checkout devel git pull git merge --no-ff hotfix-1.2.1 git push origin devel # Удаление локального хотфикс-бранча git branch -d hotfix-1.2.1
Слияние удаленного хотфикс-бранча:
# Слияние с мастером git checkout master git pull git pull --no-ff origin hotfix-1.2.1 git tag -a v1.2.1 -m 'Hotfix applied comment' git push origin master git push origin v1.2.1 # Слияние с девелом (эту секцию надо править, если у вас есть релиз-бранч) git checkout devel git pull git pull --no-ff origin hotfix-1.2.1 git push origin devel # Удаление локального хотфикс-бранча (если есть) git branch -d hotfix-1.2.1 # Удаление хотфикс-бранча с сервера git push origin :hotfix-1.2.1
В этом случае все просто - удалите локальный и удаленный хотфикс бранчи (смотря, что у вас есть) и забудьте о них.