Git: как поддерживать постоянные параллельные ветки

У нас есть проект (приложение PHP), но установка для каждого клиента меняется, иногда очень мало, а иногда и больше. Тем не менее, большая часть исходного кода является обычным явлением. Мы управляем конкретными установками в качестве параллельных ветвей для управления ветвью, и нам необходимо перенести изменения с основного на другие ветки. Такая же ситуация была решена в Git: как поддерживать (в основном) параллельные ветки с разницей в несколько раз? Самое голосованое решение заключалось в том, чтобы передать изменения между такими типами:

git pull
git checkout local
git rebase master

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

git pull
git checkout local
git merge master

Ответ 1

Это действительно зависит от того, что вы хотите делать с веткой. Да, если вы пересобираете локальный, он будет создавать неускоренные перетаскивания после перезагрузки. С другой стороны, вы будете поддерживать набор различных изменений в будущем и что на вашей ветке будет набор изменений, ЕСЛИ ОНИ БЫЛИ СДЕЛАНЫ НОВЫМ ГОЛОВОМ МАСТЕРА.

Объединение мастера на локальный, вместо этого, будет поддерживать локальное продвижение вперед во времени с мастером и будет записывать историю, как это произошло. Если вам нужно реконструировать состояние локального в прошлом, тогда вы захотите это сделать. История никогда не изменится. Но у вас будет более сложная история.

Ответ 2

Идея заключается в том, что вы используете одну общую ветвь, а две (или столько, сколько вы нужны) специфические для клиентов отрасли. Все общие изменения входят в мастер, и каждая ветвь клиента получает изменения, которые относятся только к это клиент. Периодически (когда мастер считается стабильная точка), вы слейте изменения с мастера на клиента ветвь (git checkout custA; git merge master). Это приводит к появлению новых "общий" код в ветку клиента. Вы никогда не будете сливать другой путь - это будет загрязнять мастер с помощью кода, специфичного для клиента.

Когда вы делаете доставку клиенту A, вы выписываете "custA", и отправьте это. И, конечно, аналогично для других клиентов.

Теперь позвольте сказать, что вы приобрели нового клиента, "C", и немного позже найдете что клиенты A и C хотят, но B нет. Вы создаете (aka "вилка" ) отвал мастера (git checkout -b AC_feature master), код/протестировать его, совершить фиксацию, когда вы идете, а затем объединить его в и C (git checkout A; git merge AC_feature and similarly for customer C). Вы не кодируете его в A, а затем полагаетесь на слияние A с C, потому что который получит все A в C.

Если через некоторое время вы обнаружите незначительную ошибку в этой функции, вы изменение в той же ветки (git checkout AC_feature; edit/test/commit), и затем вы объедините его в custA и custC, как указано выше.

Источник: Эти освежающие и полезные статьи от разработчика Gitolite - Sitaram Chamarty, частично написанного прямым сообщением Юнио Хамано (партнером Linus Torvalds по поддержанию Git). p >

Поддержание параллельных клиентских ветвей

http://gitolite.com/archived/special-branches.html

Последующая статья о "Фиксации" общих и клиентских ветвей:

http://gitolite.com/archived/special-branch-fixups.html

Ответ 3

Greg answer для вашего другого вопроса, похоже, рассматривает разные ветки как локальные для определенных установок, а не помещается в другие репозитории (выделено мной):

Если он локальный для системы, передайте его этой системной "локальной" ветке, иначе передайте ее "master" и переместите ее в общий репозиторий.

Вы почти всегда хотите, чтобы ускоренная переадресация перемещалась по веткам в общий репозиторий. Документация git rebase объясняет, как восстановить из восходящей перестановки (т.е. git rebase then git push -f), и это не забавно для кто-то из участников.

Для другого подхода см. Никогда не слияние:

Существуют действительные случаи, когда вы когда-то вилки с намерением никогда не сливаться, но в целом вы должны очень стараться сохранить изменения на такой вилке до минимума.

Далее автор обсуждает политику ветвления для различных выпусков клиентов в том же репозитории.