Разработка лучшей стратегии модели git ветвления

Краткий обзор

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

Модель

Мы делаем гибкие, поэтому у нас есть спринты и релизы. Каждый месяц или два мы открываем новую ветку релиза от master, которая будет стабилизирована и позже будет предоставлена ​​клиентам, которые заинтересованы в ее возможностях. Все идет нормально. В процессе разработки создаются новые клиенты. Допустим, мы начинаем работать над клиентом A и решаем, что этот клиент будет работать с определенной версией, скажем, release/1.0 поэтому мы делаем ветку release/A_1.0 и мы начинаем наше развитие там, как только мы закончим, мы объединяем release/A_1.0 -> release/1.0 и мы развернем производство release/1.0 филиал этого клиента.

Прежде чем я продолжу объяснять, в чем проблема, я установлю некоторые правила, которые мы храним:

  • однажды release филиал открыт master никогда не сливается там.
  • release/{client}_{version} ветки иногда обновляются с release/{version} филиал (номера версий должны совпадать).
  • Только hotfix ветви объединены в release/{version} ветка.
  • Перед открытием нового release/{version} ветка 2-3 предыдущая версия release ветви объединяются в master так что все исправления из этих предыдущих версий также в новой версии.
  • Исправления из предыдущей версии не допускаются один раз release/{version} филиал открыт.

В чем проблема?

Проблема плохого планирования, но это случается, и этого нельзя избежать. Допустим, мы договорились с клиентом (B) и решили предоставить ему версию 1.0, которая будет открывать филиал, что делает его release/B_v1.0 В то время как мы разрабатываем этот клиент в этом филиале, время идет, и наша команда разработчиков спринта открывает другой releaseНапример, 1.1. Иногда процесс разработки клиента занимает достаточно времени для открытия продукта, если не один, а два или три новых release/{version} ветви. Поэтому, если это произойдет, руководство и клиент могут принять решение перейти на более новую версию (скажем, 1.3 - ранее она была разработана для 1.0). Теперь то, что нужно сделать, это то, что нам нужно открыть ветку из release/1.3 для этого клиента, а затем слить ранее открытую ветку - это будет делать слияние release/B_1.0 --> release/B_1.3 и это может быть болезненным, чтобы быть сделано. Зачем?

Так как release/B_1.0 иногда обновляется с release/1.0 это означает, что все исправления из версии 1.0 будут в release/B_1.0 (этого нельзя избежать, так как некоторые исправления имеют решающее значение для развития клиента) и когда приходит время объединяться release/B_1.0 --> release/B_1.3 это будет включать все эти исправления из версии 1.0 в release/B_1.3 и позже, когда release/B_1.3 --> release/1.3 введено слияние, они будут включены в версию 1.3, что запрещено.

Что я делаю в подобных ситуациях?

Я выбираю все коммиты / слияния, которые были в release/B_1.0 и не исправления, которые пришли из release/1.0в release/B_1.3 но это может быть очень трудоемким, и ошибки могут быть сделаны также из-за того, как работает git history.

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

Есть ли у вас другие предложения, которые облегчили бы такие слияния?

Источник

1 ответ

Почему бы не управлять этими клиентами для разных репозиториев git?

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

Так что вам лучше управлять ими по отдельности. Даже если два клиента имеют одинаковые функции, их можно легко использовать в нескольких репозиториях:

# In repoA
git remote add B <URL for repo B> -f
gitk --all # find the commit of repoB you want to use in repoA
git cherry-pick <commit in repoB>
Источник
Другие вопросы по тегам