Синхронизация Git-репозиториев без доступа друг к другу и без доступа к обоим из любой системы

Question

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

• Команда A имеет доступ к серверу A, но не к серверу B
• Команда B имеет доступ к серверу B, но не к серверу A

У нас нет системы, которая имеет доступ к обоим серверам, и вряд ли скоро что-нибудь получит.

Как мы синхронизируем репозиторий в разных местах?

До сих пор мы пробовали следующий подход (-ы) с небольшим успехом.

Команда А:

• git clone --mirror https://server_a.com/repository_origin.git для получения полной копии, включая все ветви и теги из исходного хранилища

• Обернуть созданную папку в zip-файл и передать команде B

Команда B:

• Выписка из архива

• cd repository_origin.git

• git remote set-url --push origin https://server_b.com/repository_mirror.git

Подходы

1. • git push --mirror приводит к тому, что изменения команды B будут полностью отброшены, но все изменения команды A были объединены в зеркальное хранилище, то есть изменения команды B отсутствуют в зеркальном хранилище.
2. • git fetch --all правильно получает все локальные изменения команды B
   • git push --mirror приводит к тому, что изменений нет, т. Е. Изменения команды A отсутствуют в зеркальном хранилище.

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

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

Answer 1

Git был разработан для поддержки полнофункциональной совместной работы по электронной почте. В книге Pro Git есть глава , в которой обсуждается это , но в основном вы можете генерировать изменения, используя git format-patch, отправлять их с git imap-send и применять их на другая сторона с git am. Другая глава этой же книги содержит короткий пример .

Это может показаться низко технологичным, но это зрелый рабочий процесс, который хорошо работал для разработки самого Git .

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

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