В предыдущей работе я обнаружил, что легче управлять и поддерживать стабильную ветку перед выпуском (или основную, в зависимости от настройки), когда каждый разработчик работает в своей собственной ветке.У нас был только один производственный экземпляр, поэтому нет необходимости поддерживать несколько версий одних и тех же приложений.
Эта ветвь перед выпуском названа так, потому что была другая ветвь (основная), из которой мы делали наши промежуточные и производственные выпуски.Ветви были настроены таким образом, чтобы в ветку выпуска можно было объединить только код из предварительной версии.Эти слияния были нашими контрольными точками проверки кода.Сборки CI также были сделаны из этой предварительной версии, и каждый разработчик должен был перейти от «предварительной версии» к своей собственной ветви к сложным проблемам слияния миграции, когда разработка этой части работы была завершена.
Если разработчикам нужно было объединиться и работать вместе для получения определенной функции, ничто, кроме их собственных разрешений на ветки, не позволяло им работать с другими.Это хорошо работало для управления распределенными командами, где отдельные лица в каждой команде работали над отдельными / несколькими функциями.
С помощью частых (1-2 раза в неделю) 30-минутных собраний по обновлению статуса мы, как команда, принимаем решение о том, что будет входить в QA, а что нет для этого конкретного выпуска QA.
Эта система работала, но я нахожу много обид за ветки разработчиков при поиске по этой теме.Кажется, есть большой энтузиазм по поводу функции локального репозитория git.Тем не менее, кажется, что это просто разные способы решения одних и тех же проблем.Не принимая во внимание кросс-сетевые проблемы, которые решаются локальными репозиториями, такие как задержка регистрации и т. Д.