Как управлять иерархиями репозитория GIT?

Question

Я использовал git в распределенной среде (включая GitHub), в которой разработчики работают в автономном режиме, а затем переходят к центральному репо. Теперь у меня есть требование к более структурированной иерархии репозитория, потому что у нас несколько офисов. Если мы возьмем пример, у нас есть разработчики из Таллинна, которые отправят их в удаленный репозиторий. У нас также есть разработчики в Лондоне, которые будут продвигаться в их хранилище. Затем нам нужно объединить изменения между двумя удаленными репозиториями и передать их разработчикам на обоих сайтах. Следовательно, иерархия выглядит примерно так:

     
    Tallinn   -------   London 
       |                  |
 -------------      -------------
 |   |   |   |      |   |   |   |
Dev Dev Dev Dev    Dev Dev Dev Dev

Может кто-нибудь порекомендовать лучший подход для реализации этого?

Answer 1

Я бы выбрал город для размещения официального мастера, и чтобы кто-то отвечал за объединение изменений из обоих городов. У каждого города будет свое собственное репо, которое могут принять на себя разработчики, и в конце дня все изменения будут объединены с главным репо. Тогда оба репо города будут обновлены.

               master
                 | 
    Tallinn   -------   London 
       |                  |
 -------------      -------------
 |   |   |   |      |   |   |   |
Dev Dev Dev Dev    Dev Dev Dev Dev

Это не сильно отличается от того, как работает Linux. Один человек управляет хозяином, но вместо городов вещи делятся на подсистемы.

Answer 2

Если между Таллинном и Лондоном нет прямой связи (то есть вы не можете напрямую переходить из одного центрального репо в другое), это означает, что репо в Таллине и Лондоне по существу ответвление одно от другого ** (как в «использовании, например, git format-patch»).

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

Answer 3

Я бы настроил «привратника», который имеет доступ к обоим наборам репозиториев. Этот компьютер - который может быть сервером или просто подкаталогом на чьей-либо машине - имеет репозитории, настроенные с удаленными устройствами из обоих офисов Затем для каждого репо, которое требует обновления с обеих сторон:

git pull talinn
git pull london
git push talinn
git push london

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

Answer 4

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