Описание рабочего процесса для использования git для собственной разработки

Question

Компания, в которой я работаю, хочет выпускать ежемесячные выпуски, и я пытаюсь убедить их перейти на git. Я считаю, что правильный способ справиться с этим - иметь ветку интеграции для каждого выпуска (то есть ежемесячно) и иметь функциональные ветви от ветвей интеграции для новых разработок и изменений. Среда загружена взаимозависимостями, и иногда функцию приходится откладывать на другой месяц из-за задержек в требуемых функциях из других внешних систем. Проекты, как правило, будут параллельно работать в 2-3 интеграционных ветвях, и деятельность ограничивается группой людей, которые находятся в достаточно тесном контакте. (Это означает, что я подозреваю, что мы можем использовать ребазинг, пока мы находимся в последней ветви интеграции - что верно, по крайней мере, в половине случаев для половины людей)

В нем задействовано немало людей, поэтому мне действительно нужны четкие рекомендации, как это сделать, как логическое объяснение структуры ветвления / слияния, так и практические команды git, чтобы сделать это. Кто-нибудь знает такое описание, которое достаточно хорошо подходит для такого рабочего процесса?

Answer 1

логическое объяснение структуры ветвления / слияния

Структура в основном соответствует тому, что вы сказали: ветвь интеграции и ветки функций.
В этом типе рабочего процесса, как и вы, важно понимать, что вся разработка не сможет перейти к следующему выпуску.
Но с DVCS также важно понять, какую ветку можно опубликовать и клонировать.

Этот последний пункт (публикация) будет иметь большое влияние на команды слияния а именно:

• 1012 * Слияние *
• перебазироваться.

Всякий раз, когда разработчик должен объединить свою работу в любой ветви интеграции (он извлек из "центрального" хранилища), я бы порекомендовал:

# switch back to previous release tag (from where feature branches for next release where done)
$ git checkout previousReleaseTag
# create one's own private
$ git checkout -b myIntegrationBranch
# merge or cherry-pick what we want to actually put in the next release
$ git merge... from our feature branch
# rebase that private integration branch on top of actual integration branch
$ git rebase integrationBranch

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

«Частная ветвь - слияние или выбор вишни - ребазировка - локальное разрешение - слияние назад» - это необходимый рабочий процесс, поскольку нескольким группам придется объединить свою работу с общей веткой. Им нужно воспроизвести то, что они хотят опубликовать в частной ветке, прежде чем объединить это с общей веткой, иначе каждая команда может сломать то, что представлено HEAD общей ветки.

Другие подробности в вопросах:

• частота коммитов git
• управление релизами git (еще один рабочий процесс слияния)
• JC Hamano статьи (спасибо Jakub Narębski )