"Layering" репозиторий git

Question

Некоторое время назад я использую git ежедневно, и на этот раз я столкнулся с проблемой, которую могу описать следующим образом.

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

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

Далее, есть ветка для каждого сайта, который использует этот исходный код.Все эти ветви (скажем, site1 , site2 и site3 ) создаются из главной ветви, и каждый сайт клонирует правильную ветвь.

Что ж, это казалось хорошей идеей, пока я не начал вносить изменения везде.

Если бы я внес изменение в ветку site1, и мне нужно было скопировать это изменение в ветку site2, я бы выбрал вишню из одноговетвь к другому.Слияние здесь не может быть и речи, так как есть другие изменения в ветке site1, которые не относятся к ветке site2.Есть ли какое-то другое, более изящное решение для такой ситуации или сбор вишни именно для этой цели?

Теперь настоящая «проблема» для меня - это когда я меняю мастера, а потом яхочу скопировать все эти изменения во все ветви.Естественно, учитывая тот факт, что все ветви являются потомками мастера, и что я делаю хочу эти изменения во всех ветвях сайта *, я переключаюсь на каждую ветку и объединяю мастера.

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

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

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

Я не знаю, мне нравится простота, и, возможно, я не привык видеть сложные графики, подобные этой (которая будет только усложняться с каждымбоюсь, после слияния).

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

Итак ... Есть какие-нибудь идеи, опыт, предложения, которыми вы не против поделиться?

ОБНОВЛЕНИЕ: Я выбираю решение, описанное в моем комментарии к аккответ.Спасибо всем, кто внес свой вклад!

ОБНОВЛЕНИЕ 2: Несмотря на то, что это не тесно связано с этим вопросом, недавно я наткнулся на эту модель ветвления , которая кажется подходящейпрактически для любого организованного цикла разработки с GIT в качестве основного DVCS.Это действительно хорошее чтение.Рекомендуется.

Answer 1

Альтернативный ответ:

Вы можете переместить абстракцию с уровня ветки на уровень хранилища.Создайте один основной репо с мастер-веткой.Клонируйте этот репозиторий для каждого сайта.После внесения изменений в основную ветку внесите эти изменения в каждое хранилище сайта.Таким образом, вам потребуется только одна основная ветвь для каждого репо.

---

Исходный ответ:

Когда основная ветвь была изменена, вы можете переместить другие ветви в обновленную основную ветвь.Предположим, у вас есть pl_site, основанный на некотором коммите на мастере, и этот мастер изменился:

 o---o---o---o---o  master
         \
          o---o---o---o---o  pl_site

После того, как вы перебазировали pl_site, он будет выглядеть так:

 o---o---o---o---o  master
                  \
                   o'---o'---o'---o'---o'  pl_site

Обратите внимание, что коммитына перебазированной версии pl_site новые.Теперь pl_site содержит изменения, которые были сделаны на master.

Команды:

$ git checkout pl_site
$ git rebase master

Answer 2

У меня нет хорошего ответа для вас, потому что ваша проблема сложна и имеет сложные решения.

Вариант 1: Refactor

Вы сказали, что разные сайты "в основном один и тот же сайт". Поэтому перенесите их в разные проекты и оставьте main_site в проекте отдельно. Другие сайты будут включать main_site в качестве подпроекта.

Итак, для баннера ...

en_site/
en_site/images/banner.jpg
en_site/master/
en_site/master/images/banner.jpg

Код вашего веб-сайта, сценарий конфигурации, сценарий развертывания или что-либо еще обеспечит выбор images/banner.jpg вместо master/images/banner.jpg. Возможно, когда вы развертываете сайт, сначала копируется master/images, а затем копируется images, возможно, вы делаете что-то более сложное.

Это может быть много работы. Однако, если вы посмотрите на историю, вы получите что-то вроде этого:

en_site: A -> B -> C -> D
de_site: E -> F -> G -> H -> I
main_site: J -> K -> L -> M -> N -> O

Вариант 2: использовать Darcs

В Darcs вы можете перемещать патчи от ветки к ветке. Некоторые коммерческие VCS, вероятно, могут сделать это тоже. Таким образом, ваши ветви будут выглядеть так:

master: patch1 patch2 patch3 patch4
en_site: patch1 patch2 patch3 patch4 en1 en2 en3
de_site: patch1 patch2 patch3 patch4 de1 de2 de3

Предположим, вы хотите перенести патч en2 на немецкий сайт.

de_site: patch1 patch2 patch3 patch4 de1 de2 de3 en2

Вуаля. Однако это не так чисто, как кажется. Поклонники Darcs укажут, что эта модель патча соответствует нашей концептуальной модели «перемещения патча в другую ветку», однако это заслоняет тот факт, что вам все равно придется протестировать, чтобы убедиться, что патч en2 не сломать все, когда вы положите его на de_site.

Например, что если en2 внесет изменения в ту же часть кода, что и de1? Что тогда? Вы должны объединить вручную, независимо от того, какую VCS вы используете. Для каждого очевидного случая, подобного этому, есть другой случай, который VCS не обнаружит, и вам придется проверить его самостоятельно.

Мой опыт

Когда я впервые начал использовать git, казалось, что git merge было волшебством. Однако никакие хитрости VCS не скрывают того факта, что ваш сайт имеет очень сложные взаимозависимости. Вы можете либо реорганизовать свой сайт, чтобы удалить взаимозависимости, либо надеяться, что история VCS не станет настолько сложной, что вы больше не сможете ее понять.

Компромисс между новыми ветками, новыми проектами и рефакторингом вещей в библиотеки - это тонкий компромисс. Поддерживать большую коллекцию наборов патчей - это гораздо больше, чем поддерживать большую коллекцию проектов, в которых все используют общую библиотеку, (большой) объем работы, необходимый для рефакторинга, может быстро окупиться. Или не может.