Синхронизация двух размещенных репозиториев git

Question

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

Разветвления не нужно синхронизировать сразу, поэтому я думал о том, чтобы использовать какое-то задание cron для извлечения из одного и нажатия на другое (все разработки сделаны одно, второе - в настоящее время используется почти как резервная копия).

Я думал об использовании что-то вроде:

for b in `git branch -r | grep <get only one remote's branches>` 
do 
    git update-ref refs/heads/$b origin/$b 
done 
git push --all origin2 

в git submodule foreach, но я не уверен, что это лучший способ сделать это.

я не нашел простой способ, чтобы убедиться, что удаленные филиалы в origin также удаляются в origin2 (для этой цели, любая отрасль, которая не присутствует в origin можно считать, были удалены).

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

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

Может ли разумнее просто зеркально отражать каждое репо индивидуально, не пытаясь сделать это, используя подмодуль foreach?

Любые предложения?

Answer 1

я не нашел простой способ, чтобы убедиться, что удаленные филиалы в происхождении, также удаляются в origin2

Вот что fetch.prune для:

git config fetch.prune true 

что приводит меня к другому подходу: git pull вместо git push (таким образом, вы обойдете проблему с открытым репо, которая является предпочтительной при использовании git push)