Как управлять несколькими версиями кодов в Git?

Question

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

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

Допустим, в настоящее время все ветви (все клиенты) начинаются с одной и той же истории коммитов, то есть ::1005*

git log на ветке: master, client1, ..., client900:

• commit10
• commit9
• ...
• commit1

Затем из ветви master я создал одну ветку разработки для feature_a, затем я разработал весь необходимый код для этой функции,

Мой план заключается в развертывании feature_a на 100 клиентах, т. Е. Объединении всех коммитов от feature_a до client1 до client100.

Все прошло без нареканий.

Затем из ветви master снова я создал одну ветку разработки для feature_b, затем я разработал весь необходимый код для этой функции,

Теперь я планирую развернуть feature_b на всех клиентах, то есть объединить все коммиты от feature_b до client1 до client900.

Цель состоит в том, чтобы от client1 до client100 иметь 2 функции, в то время как у остальных есть только 1 дополнительная функция.

Поскольку разработка feature_a и feature_b требует от меня изменения многих одинаковых файлов, это вызовет конфликт слияния в ветви client1 на client100,

Исправление сотен, если не тысяч конфликтов слияния, для меня не вариант, есть ли лучший способ решить эту проблему? или есть какой-то лучший дизайн или подход к архитектуре git repo, чтобы проблема с развертыванием функции для некоторых и всех клиентов была бы беспроблемной?

Answer 1

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

---

Как говорится, для "небольшого" количества функций вы можете улучшить свою ситуацию с помощью тегов.

Вместо того, чтобы каждый клиент имел уникальную ветвь, присвойте каждому клиенту уникальный тег. Большинство операций git выполняются одинаково, но значительно проще изменить код, на который они указывают.

Тогда ваши ветви должны быть основаны на функциях. Таким образом, у вас будет feature_a, который содержит только код для функции а. Тогда у вас есть feature b с кодом только для функции б. Тогда у вас есть feature_a_b, который содержит обе функции a и b - и вам нужно разрешать конфликты только в одном месте.

Для развертывания вы просто меняете теги так, чтобы они указывали на нужную вам ветку - client1 до client100 указывают на feature_a_b и client101 до client900 указывают на feature_b.

Тогда предположим, что client562 решает обновить (или что-то еще), и теперь им нужна функция a. Очень просто - просто измените тег client562, чтобы он указывал на feature_a_b. Объединение не требуется!

---

Но что, если есть изменения, специфичные для клиента?

Создайте клиентскую ветку из функциональной ветви и внесите в нее изменения.

Но что, если есть изменения, характерные для клиента, и они меняют функции?

С клиентской ветвью просто переназначьте клиентские коммиты в соответствующую функциональную ветвь.

---

Чем сложнее вводить новые функции, тем сложнее становится, в частности, вам понадобится 2^(n-1) ветвей функций, где n = количество функций. На практике это может быть меньше, если для работы других функций должны присутствовать определенные функции (т. Е. Функция j имеет смысл только при наличии функции c), но это справедливое приближение.

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