我们在中央服务器上有一个共享的“开发”仓库，有不同的分支，称之为v4，v5，v6
开发人员（“Alice”）已经提交了v6，一切看起来都不错。我有一个post-receive hook，它已经获取了所有相关的细节，持续集成服务器可以克隆repo并检查这个提交并对它进行处理 - 一切都很棒。
然而，当我在我的个人副本和git pull中签出v6时，我根本没有得到“Alice”的提交。它根本没有显示在日志中，也没有被拉到我的机器上。
当我通过cgit浏览repo时，提交没有显示在“logs”中 - 但是如果我从SHA和分支构造查看URL，我可以看到提交。
就像爱丽丝已经推到了中央（裸）回购中的一个看不见的平行v6分支。如何让这个看不见的分支显露出来？
那么可能发生了什么？在Alice执行提交前几个小时，我使用git push origin :v6命令删除了中央存储库上的v6分支。 v6是空的并且基于原始主服务器，但我希望它来自最新的v5工作。为此我然后检查了v5，做了一个git pull然后检查了这个到v6。然后我将这个v6推送到共享仓库。
所以看起来我的删除工作不起作用，不知何故，Alice推送到v6而不是git认为是v6的v6。
我的修复？修改裸存储库上的refs / heads / Release_6以包含Alice提交的SHA。
但这是正确的做法吗？ git如何在没有严重抱怨的情况下维护或允许影子分支？ Git没有抱怨我的回购或Alice的..
ANSWERED： 看起来像我的笨拙的rebase尝试，裸的repo refs / heads / v6得到了SNAFU'd。在将Alice的提交的SHA写入裸repo refs / heads / v6后，一切都会出现在它应该做的事情上。
服务器“裸”仓库实际上是从一些原创作品中克隆出来的（使用--bare）。原始仓库有v4，v5，v6。
周末有一个脚本在裸露的回购中运行了git fetch origin +refs/heads/*:refs/heads/*，我猜，因为“+”修饰符，我们用“改编”创建了“新”v6。遗留下来的“v6来自原始回购。
这解释了为什么v6工作似乎有效，然后在周末消失了。
没有git的错，很明显是我自己制造的错误。是时候坐在顽皮的一步了。
答案 0 :(得分：0)
你还没有给出我怀疑的所有命令，但这是我的看法。
你，Alice和'origin'（中央存储库）都有一个v6分支。这些将在您的存储库v6，alice / v6，origin / v6中调用（假设您有远程指向alices存储库）。你用'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。