"保持多个（非裸）Git 存储库同步的最佳/最简单方法”建议使用更新后挂钩来处理此类贡献。
然而，有一个更直接的解决方案：
As The OP zedoo评论，git 上的线程推送到非裸存储库（由 Git 维护者 Junio C Hamano 于 2007 年撰写）详细信息：
（这是一个很好的例子适合推送到非裸仓库的情况)
receive-pack 没有更新HEADreflog 作为其更新实际分支，而不是HEAD.
如果你推到HEAD你应该看到HEAD也有转发条目。
分裂又怎样HEAD当你推送到底层分支时，并且使HEAD非符号引用？
我认为不需要任何复杂化，并且我认为有人提到了很好的例子，这是一个受防火墙保护的主机，只能被推入.
在那个例子中，即使他知道他可以在理想世界中反向获取，但网络配置不允许他这样做，因此需要推动.
为了理智地处理这个问题，在非裸存储库之间推送的人可以忘记推送到分支头.
相反，他们可以将他们的推送安排为他们的取物的真实镜像他们希望能做到的.
为了显示：
On repo A这只能被推入，如果你could从仓库获取B， 你会：
$ git fetch B
像这样的东西：
[remote "B"] fetch = refs/heads/*:refs/remotes/B/*
但不幸的是，因为你只能推进A from B，你会运行这个B反而：
$ git push A
with:
[remote "A"] push = refs/heads/*:refs/remotes/B/*
当你执行完你的推送后，你带着 repo 来到机器前A并记住你所做的只是“的镜像”git fetch B"， 你会：
$ git merge remotes/B/master
你就完成了。
换句话说，不要想refs/remotes/B作为用于“的东西”git fetch".
其目的是跟踪远程存储库B's heads.
您可以通过在存储库中发出 fetch 来维护该层次结构A.
您可以在存储库中发出推送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 ...
where
-
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失败的）。
If I were有时错误地推入实时分支让我很恼火，我会切换到单独的远程布局并推入remotes/origin/*层次结构，并且会有
在那之后就真的没什么可担心的了。
