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

Question

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

git pull
git checkout local
git rebase master

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

git pull
git checkout local
git merge master

Answer 1

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

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

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

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

Источник: Эти очень понятные и полезные статьи от разработчика Gitolite - Ситарама Чамарти, частично написанные при непосредственном участии Хунио Хамано (партнера Линуса Торвальдса по поддержке Git) .

Ведение параллельных веток клиента:

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

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

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

Answer 2

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

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

Answer 3

Ответ Грега на ваш другой вопрос, по-видимому, рассматривает различные ветви как оставшиеся локальными для определенных установок, а не помещенные в другие репозитории (выделение добавлено):

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

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

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

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

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