git commit推送到远程ok上的分支，但不能拉到另一个开发人员的repo

我们在中央服务器上有一个共享开发repo，它有不同的分支，称它们为v4、v5、v6

一位开发人员Alice已经承诺使用v6，一切看起来都很好。我有一个post-receive钩子，它收集了所有相关的细节，持续集成服务器可以克隆repo，检查这个提交并处理它——一切都很好

然而，当我在我的个人副本和git pull中签出v6时，我根本没有得到Alice所做的提交。它不会出现在日志中，也不会被拉到我的机器上

当我通过cgit浏览repo时，提交不会显示在日志中，但是如果我从SHA和分支构造查看URL，我可以看到提交

这就像Alice在中央裸回购协议中推到了一个看不见的平行v6分支。我怎样才能让这根看不见的树枝显露出来呢

那么会发生什么呢？在Alice提交之前几个小时，我使用git push origin:v6命令删除了中央repo上的v6分支。v6是空的，基于原始主版本，但我希望它是从最新的v5版本衍生出来的。为此，我检查了v5，做了一个git拉，然后检查了v6。然后，我将此v6推送到共享回购

所以看起来我的删除不起作用了，不知怎的Alice推到了v6，而不是git认为是v6的v6

我的计划？修改裸回购协议上的REF/heads/Release_6，以包含Alice提交的SHA

但这是正确的做法吗？git如何在没有严重抱怨的情况下维护或允许影子分支？Git没有在我的回购协议或Alice的

答复: 看起来，我笨拙的重设基准的尝试破坏了裸回购参考/heads/v6。在编写Alice对裸回购refs/heads/v6的承诺的SHA之后，它应该做的一切都出现了

验尸分析。 服务器裸机repo实际上是使用-bare从一些原始作品中克隆出来的。最初的回购协议有v4、v5、v6

周末运行了一个脚本，它在裸repo whcch上执行了git获取origin+refs/heads/*：refs/heads/*的操作，我想，由于+修饰符，我们轻松地重写了我们使用原始repo的遗留v6创建的新v6

这就解释了为什么v6的工作看起来很有效，但在周末就消失了

---

不是git的错，很明显是我自己犯的错误。是时候坐在顽皮的台阶上了。

我怀疑你没有发出所有的命令，但在我看来是这样的

您、Alice和中央存储库的“origin”都有一个v6分支。假设您有一个远程指向alices存储库的对象，这些将在您的存储库v6、alice/v6、origin/v6中调用。您使用“git push origin:v6”删除了中心一个。这就给您和alice留下了v6分支，除非您还使用“git branch-d v6”删除了本地分支，或者在推送之后执行了“git fetch origin-prune”

此时没有原点/v6。alice/v6和本地v6引用同一个提交。Alice开始工作并将其推到origin/v6，重新创建分支，并在顶部添加新的工作

现在，您可以获取在本地返回origin/v6的数据。但是，除非您签出v6并执行git pull或git merge origin/v6，否则您的本地分支将不会得到更新以匹配origin/v6

---

这里真正的问题是您计划在当前的v5上重新设置v6的基础。如果你想这样做，你必须让所有的开发者都同意。如果你在爱丽丝作出承诺之前就这样做了，她会很生气的。重新阅读Git书籍中关于重新调整已发布分支的部分，考虑将v65中的新工作合并到v6中。

服务器可以检查此提交并处理它。。。那么服务器是不是一个空的repo？是的-服务器repo是空的-它用于协作。您提到的评论与我们的集成服务器有关，该服务器克隆了bare以获得最新的提交。公平评论-我认为在我笨拙的v6重基和Alice的签出和提交之间存在竞争条件。我刚刚将Alice的SHA写到refs/heads/v6，并直接指向它。