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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

# switch back to previous release tag (from where feature branches for next release where done)
$ git checkout previousReleaseTag
# create one 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 соответствующей ветки интеграции.

"Частный филиал - слияние или выбор вишни - перебаза - локальное разрешение - слияние" - это необходимый рабочий процесс, поскольку нескольким командам придется объединить свою работу в общую ветку. Им нужно воспроизвести то, что они хотят опубликовать в частной ветке, прежде чем слить ее в общую ветку, иначе каждая команда может сломать то, что представлено ГОЛОВКОЙ общей ветки.

Другие вопросы в вопросах: