0

我们在中央服务器上有一个共享的“开发”存储库，具有不同的分支，称为 v4、v5、v6

开发人员（“Alice”）已提交 v6，一切看起来都不错。我有一个接收后挂钩，它收集了所有相关细节，持续集成服务器可以克隆存储库并检查这个提交并处理它——一切都很好。

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

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

就像 Alice 已经推送到中央（裸）repo 中的一个不可见的并行 v6 分支。如何让这个无形的分支显露出来？

那么可能发生了什么？在 Alice 提交之前几个小时，我使用命令删除了中央仓库上的 v6 分支git push origin :v6。v6 是空的，基于原始母版，但我希望它源自最新的 v5 作品。为此，我检查了 v5，进行了 git pull，然后将其检查到 v6。然后我将此 v6 推送到共享仓库。

所以看起来我的删除不起作用，并且以某种方式 Alice 推送到了 v6，而不是 git 认为的 v6。

我的修复？修改裸仓库上的 refs/heads/Release_6 以包含 Alice 提交的 SHA。

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

回答： 看起来裸 repo refs/heads/v6 被我笨拙的 rebase 尝试弄坏了。在将 Alice 的提交的 SHA 写入裸 repo refs/heads/v6 之后，一切都出现在它应该做的事情上。

POST_MORTEM 分析。

服务器“裸”存储库实际上是从一些原始工作中克隆的（使用 --bare）。原始仓库有 v4、v5、v6。

周末有一个脚本在git fetch origin +refs/heads/*:refs/heads/*裸仓库上运行，我猜是因为“+”修饰符，很容易覆盖了我们用原始仓库中的“旧”v6 创建的“新”v6。

这就解释了为什么 v6 工作似乎有效，然后在周末消失了。

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

4

1 回答 1

0

您还没有给出我怀疑的所有命令，但这就是我的看法。

你、Alice 和“origin”（中央存储库）都有一个 v6 分支。这些将在您的存储库 v6、alice/v6、origin/v6 中调用（假设您有一个远程指向 alices 存储库）。你用你的'git push origin:v6'删除了中心那个。这让您和 alice 拥有 v6 分支（除非您还使用 'git branch -d v6' 删除了本地分支或在推送后执行了 'git fetch origin --prune'）。

此时没有origin/v6。alice/v6 和您的本地 v6 指的是同一个提交。Alice 确实工作并推动到 origin/v6 重新创建分支，并在顶部添加新工作。

您现在 fetch 将在本地带回 origin/v6。但是除非您签出 v6 并执行 git pull 或 git merge origin/v6，否则您的本地分支将不会更新以匹配 origin/v6。

您真正的问题是您计划在当前 v5 上重新设置 v6。如果你想这样做，你必须让所有相关的开发人员都同意。如果你在 Alice 做出承诺之前就这样做了——应该会非常恼火。重新阅读 Git 书籍中关于变基已发布分支的部分，并考虑将新工作从 v65 合并到 v6。

于 2013-02-04T15:09:49.657 回答