Каковы некоторые из наиболее распространенных схем ветвления Git / жизненных циклов коммитов?

Question

Во-первых, извините, если это дубликат, но я попытался найти, и все, что я мог найти, было что-то о том, как создавать ветки в Git и еще много чего.Это не то, что я ищу так много;Я пытаюсь выяснить, как разные люди настраивают свои ветки Git в соответствии с их рабочим процессом.

Позвольте мне привести пример того, как наша компания делает это:

1. Разработчикфиксирует свою собственную ветку, локально
2. Разработчик отправляет коммит на свой удаленный компьютер, где система непрерывной сборки проверяет его, а другой разработчик просматривает его
3. Если проверка / сборка проходит, фиксация объединяется вв ветвь QA (если она терпит неудачу, больше коммитов выполняется до тех пор, пока проверка / сборка не пройдут)
4. Если коммит не проходит QA, делается обратная фиксация, чтобы получить его
5. После достаточного QAкоммиты готовы, наша ветка master получает коммиты (ветка QA основана на нем, поэтому слияния не требуется)
6. Периодически ветки берутся из ветки master и используются для выпуска «в дикий».Если здесь обнаружены проблемы, для удаления кода снова будет использоваться возвратный коммит
7. После выпуска разработчики переназначают свои ветви в основную ветку (получая как свои предыдущие коммиты, так и коммиты других разработчиков)

Теперь есть некоторые проблемы с этой системой;Я отмечу некоторые из них в комментариях, но я на самом деле не ищу «пожалуйста, исправьте нашу систему для меня», я просто пытаюсь увидеть, какие другие варианты ветвления мы могли бы использовать вместо этого, чтобы я мог взвеситьразличные возможности.

Итак, если вы работали в нескольких компаниях, которые используют Git (или даже лучше, если вы какой-то консультант, который видел множество настроек Git), не могли бы вы поделиться: какразные компании настраивают филиалы Git (и перемещают коммиты между ними), чтобы облегчить различные этапы разработки ... и все это, пытаясь быть настолько минимально раздражающим, насколько это возможно?Я уверен, что должны быть какие-то общие шаблоны ... но я понятия не имею, что они собой представляют.

PS Если вы видели только одну настройку Git, но думаете, что она интересная, непременно отправляйтеЭто.Тем не менее, я хотел бы наградить ответ тем, кто предоставит наилучшую разбивку возможных вариантов, и я ожидаю, что это придет от того, кто видел несколько установок Git.

Answer 1

Сейчас я управляю несколькими командами, которые используют Git, и мы разработали стратегию, которая очень хорошо работает для нас.

• Мастер ВСЕГДА является копией ТОЧНО того, что находится в производстве.Когда код освобождается, текущая ветвь быстро пересылается мастеру, и добавляется тег, чтобы выпуск был помечен вовремя, и мы можем захватить код, если нам когда-либо понадобится.
• Разработчики имеют свободучтобы работать так, как им нравится в отношении их ветвей, однако для ветвей функций у нас обычно есть одна ветвь для каждой функции, и несколько разработчиков объединяются в эту ветку и из нее, чтобы участвовать в работе над этой функцией.
• КогдаПришло время для кандидата на выпуск, создана ветка RC_XXX, и все ветки функций, которые находятся достаточно далеко друг от друга, объединены в ней.Затем это проверяется, и исправления ошибок на этом ветвятся.
• Когда все сказано и сделано, ветка RC_XXX запускается в производство, и после того, как она "зависает" в течение нескольких дней, мы продвигаем ееОсновные и новые ветви функций затем основываются на нем.

Это работает очень хорошо, поскольку оперативные исправления в отношении производства легко создавать и развертывать, просто разветвляя мастер, а разработчики могут переходить к этой функции.ветви, чтобы тянуть в зависимости при необходимости.

Answer 2

Как насчет этого (я игнорирую то, что разработчики имеют на своей машине):

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

Answer 3

«После релиза разработчики перебазируют свои ветки»: ой ...

Я не являюсь консультантом Git (пока), но по своему опыту разработчики должны рекламировать свою работу гораздо чаще (чем только "сразу после релиза").
В противном случае, как вы упоминаете в своем комментарии, это приводит к большому количеству «git revert» (что работает, но должно оставаться исключительным случаем, а не общим исправлением).

Одноранговая совместная работа возможна, но примите немного дисциплины, поскольку требует настройки чистого репо и локального протокола .