Git推送到refs/remotes/mine/master

Question

我正在跟踪一个远程存储库，即我有refs/remotes/joe/master。

我知道我想尽快将joe的更改放到我的存储库中。

我不想使用fetch，因为当他提交时，我可能不在计算机旁。所以我告诉他:我可能出去买东西了，所以请把你的修改推到refs/remotes/joe/master上。

我希望他的更改尽快出现在我的存储库中的原因是，他在晚上关闭了他的计算机，所以当我从购物回来时，我就不能拿到他的更改。

我知道joe应该只设置一个空的公共存储库，但这是一种开销。

在这种情况下，推动refs/remotes/joes/master是一件可以做的事情吗？

Answer 1

"best/simplest way to keep multiple (non-bare) Git repos in sync“建议使用更新后挂钩来处理这种贡献。

但是，有一个更简单的解决方案：

正如OP zedoo评论的那样，thread on git push to a non-bare repo (由Git维护者Junio C Hamano在2007年编写)详细介绍了：

(这是的一个很好的例子，在这种情况下，推送到非纯回购是合适的)

receive-pack没有更新HEAD reflog，因为它更新了实际的分支，而不是HEAD。

如果你推送的是HEAD，你也应该看到HEAD的reflog条目。如果在推送到底层分支时拆分HEAD，并使HEAD成为非符号引用呢？我认为不需要任何复杂的东西，而且我认为有人提到了一个很好的例子，那就是一个只能推送到中的有防火墙的主机。

在那个例子中，即使他知道他可以在理想世界中以相反的方向获取，但网络配置不允许他这样做，因此需要一个推送。

为了理智地处理这一问题，在非裸存储库之间推送的人可以忘记推送到分支头部。

取而代之的是，他们可以安排他们的推送成为他们的fetch 的真正的镜像，他们希望可以做。

举例说明：

在只能推入的repo A上，如果您可以从repo B获取，您将：

$ git fetch B

使用类似于以下内容的

：

[remote "B"] fetch = refs/heads/*:refs/remotes/B/*

但不幸的是，因为您只能从B推送到A，所以您将在B上运行以下代码：

$ git push A

具有以下特性：

[remote "A"] push = refs/heads/*:refs/remotes/B/*

在您执行推送之后，您来到机器上，上面有A

，记住您所做的是的镜像，您将：

$ git merge remotes/B/master

，你就完了。

换句话说，不要把refs/remotes/B 看作是用于"**git fetch**".的东西

它的目的是跟踪远程存储库 B**'s heads**。

您可以通过在存储库A中发出fetch来维护该层次结构。

您也可以在存储库B中发出push来执行此操作。

我几乎每天都会推入一个实时存储库。

我典型的一天是这样结束的：

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 ...

，其中

1. gitster是我的私有开发machine
2. kernel.org是friendly提供给我的机器folks
3. Meta是我'todo‘分支的签出
4. 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 计算机后，我要做的第一件事就是运行'**master**‘

’**master**‘。

如果你认为'**push**‘是'**fetch**’的镜像，你就会明白为什么。

这就像在kernel.org机器上发出"git fetch“命令，从我的私人机器上检索热脱机的印刷品，然后"git merge”它(通常是"git pull“作为一个步骤)。

然而，有时候我不小心把'next‘签出来了。

如果我发现我把非'master‘签出了，我会在做其他事情之前做"git reset --hard HEAD“，我不希望我的推送有时会导致分离的HEAD，有时不会。

我不想丢失我最后在哪个分支上的信息(因为我下一步要做的是找出哪个分支Meta/Doit出现故障)。

如果我对有时错误地推入活动分支感到足够恼火，我会切换到单独的远程布局并推送到remotes/origin/*层次结构，然后就真的没有什么可担心的了。