Git: наличие двух репозиториев в режиме «push / pull» (или 1 синхронизация в режиме «push / pull» и 1 синхронизация)

Question

Мы работаем на нескольких географически отдельных сайтах.

Сегодня у меня есть все наши git-клоны, живущие на одном сайте A. Затем пользователи с сайта B должны выполнить ssh, чтобы сделать git-клон или внести изменения.Это пустые репозитории, в которых обновление происходит через нажатия.

В идеале, для производительности git clone / push я бы хотел ограничить необходимость проходить через ssh.

Я хотел бы иметькопия git repo X находится на сайте A и сайте B ... и между ними есть механизм синхронизации.ИЛИ чтобы X работал на обоих сайтах, но позволял только нажимать на A (и правильно настроить его во время клонирования на B)

Меня беспокоит случай, когда кто-то на сайте A отправляет изменения в репона сайте A в то же время, когда кто-то на сайте B выдвигает действительно противоречивое изменение в репо на сайте B.

Существует ли какое-либо решение для синхронизации, встроенное в git для таких распределенных открытых репо, как этот?

Или способ заставить клона из X установить источник / родительский элемент для X с другого сайта?

спасибо,

-Джон

Answer 1

Есть несколько способов сделать это. Похоже, что вы в основном хотите, чтобы люди на удаленном участке B были ближе.

Поскольку репозитории git не вносят много изменений в существующие файлы (в основном только файлы refs /head), использование чего-то вроде rsync прекрасно подходит для создания резервных / дублирующих копий репо. Таким образом, у вас может быть репозиторий на сайте B, с которого люди могут получать / извлекать на сайте B.

Это не совсем решает проблему, связанную с обоими сайтами-push-to-the-same-branch (эта проблема неразрушающая; в худшем случае кому-то придется создать коммит слияния и отправьте его в оба репозитория, чтобы согласовать наборы исправлений).

Чтобы исправить это, вы можете сделать сайт A основным репозиторием, а сайт B - ведомым только для чтения. Есть опция, которую вы можете указать в вашем .git / config, которая описана на странице руководства git-fetch: pushInsteadOf. Скажите, что ваши URL-адреса "ssh: // siteB" и "ssh: // siteA". Конфигурация для поддержки этого будет выглядеть примерно так:

[url "ssh://siteB"]
   pushInsteadOf = ssh://siteA

Answer 2

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

Если пользователи с сайта B могут подключиться по ssh к сайту A, они должны иметь возможность извлекать / извлекать напрямую из репозитория на узле A - push / pull через ssh является одним из основных способов работы с удаленными устройствами в git. Посмотрите на справочную страницу - вы увидите ssh URL в списке.

Итак, на сайте B вы просто добавили бы пульт:

git remote add siteA ssh://user@site.A/path/to/repo.git

Если у вас действительно плохие ограничения пропускной способности, и вам нужно очень часто использовать push / pull, я полагаю, это действительно может быть проблемой производительности? У меня никогда не было с этим никаких проблем.

Теоретически вы можете задать два центральных репо-хука после обновления, которые сразу же подталкивают к другому центральному репо. Это будет работать до тех пор, пока не произойдет толчок в обоих направлениях одновременно (может быть, это маловероятно?) - тогда вам потребуется настоящее слияние, требующее хранилища не-голых данных и, возможно, человеческого интегратора для решения конфликтов. Но пока нет одновременной подачи, репо всегда будут в одном и том же месте, и вам не придется беспокоиться о конфликтах. Если B обновляется, A также обновляется, и пользователь, пытающийся вставить что-то конфликтующее в A, будет вынужден разрешить это самостоятельно.