" лучший / самый простой способ синхронизировать несколько репозиториев Git (не обнаженных) " предлагает справиться с такого рода вкладом с помощью ловушки после обновления.
Однако есть более простое решение:
Как комментирует OP zedoo , нить о git-толчке к непроигрышному репо (написанный сопровождающим Git Junio C Hamano, еще в 2007 году), подробно:
(и это отличный пример случая, когда уместно подтолкнуть к непроигрышному репо )
receive-pack не обновляет рефлог HEAD, поскольку обновляет фактическую ветвь, а не HEAD.
Если вместо этого вы нажали HEAD, вы также должны увидеть запись HEAD reflog.
А как насчет разделения HEAD, когда вы нажимаете на базовую ветвь, и превращаете HEAD не в symref?
Я не думаю, что какое-либо осложнение необходимо, и я думаю, что кто-то упомянул хороший пример, который представляет собой хост с огненной стенкой, который можно вставить только в .
В этом примере, хотя он знает, что в идеальном мире он может получать данные в обратном направлении, конфигурация сети не позволяет ему сделать это, , следовательно, необходимо нажать .
Чтобы справиться с этим разумно, люди, которые проталкиваются между не голыми репозиториями, могут просто забыть о том, чтобы проталкиваться в головки веток .
Вместо этого они могут расположить свои толчки так, чтобы они были истинным зеркальным отражением их выборки , которую они хотели бы сделать .
Для иллюстрации:
В репо A, в который можно вставить только, если вы могли бы получить из репо B, вы бы:
$ git fetch B
примерно так:
[remote "B"] fetch = refs/heads/*:refs/remotes/B/*
Но, к сожалению, потому что вы можете нажать только на A с B, вы должны запустить это на B вместо:
$ git push A
с:
[remote "A"] push = refs/heads/*:refs/remotes/B/*
И после того, как вы выполняете толчок, вы приходите к машине с репо A и, помня, что то, что вы сделали, было зеркальным отображением "git fetch B" , вы должны:
$ git merge remotes/B/master
и все готово.
Другими словами, не думайте о refs/remotes/B как о чем-то, что предназначено для использования "git fetch".
Его цель - отслеживать заголовки удаленного репозитория B .
Вы поддерживаете эту иерархию, выполняя fetch в репозитории A.
Для этого вы также можете нажать push в репозитории B.
Я вставляю в репозиторий почти каждый день.
Мой обычный день заканчивается так:
gitster$ git push kernel-org-private
gitster$ ssh kernel.org
kernel.org$ git merge origin
kernel.org$ Meta/Doit -pedantic &
kernel.org$ exit
... go drink my tea ...
, где
gitster моя личная машина для разработки kernel.org - машина, предоставленная мне дружественными людьми k.org Meta - это проверка моей ветки 'todo' и Doit - это скрипт для построения всех четырех открытых веток.
Я всегда оставляю 'master' отмеченным в моем kernel.org хранилище, и загрузка с моей частной машины выполняется (я все еще использую компоновку без отдельного удаленного управления):
Push: refs/heads/master:refs/heads/origin
Push: refs/heads/next:refs/heads/next
Push: +refs/heads/pu:refs/heads/pu
Push: refs/heads/maint:refs/heads/maint
Итак, первое, что я делаю после входа в систему на kernel.org, - это запускаю "git merge origin", чтобы обновить 'master'.
Если вы думаете, что «push» является зеркальным отражением «fetch», вы поймете, почему.
Это похоже на команду «git fetch» на kernel.org машине, чтобы получить горячую печать с моей частной машины, а затем «git merge» (обычно «git pull» делает это как
один шаг).
Однако иногда я случайно оставляю 'next' отмеченным.
Если я обнаружу, что я оставил не отмеченным 'master', я бы сделал "git reset --hard HEAD", прежде чем делать что-либо еще, и я не хочу, чтобы мой толчок иногда приводил к отключению HEAD, а иногда нет.
Я не хочу потерять информацию о том, в какой ветке я находился последним (потому что следующее, что я хотел бы сделать, это выяснить, в какой ветке Meta / Doit произошел сбой).
Если бы я был достаточно раздражен тем, что иногда ошибочно толкал в живую ветвь, я бы переключился на отдельную удаленную компоновку и протолкнулся в иерархию remotes/origin/*, и там будет
после этого момента действительно не о чем беспокоиться.