Question

我对标题不满意，但我觉得我的解释过于复杂，最后就像上面一样简单。

我们正在使用一个分支模型，它具有一个中心原点repo，一个“develop”分支，在该分支上有特征分支。

我在开发分支上开发了一组本地更改，例如：

develop (A)- (D1) - (D2)
         \ - (F1) - (F2) - (F3) - (F4)

此时我在我的git gui中滑倒了，而不是将我的功能分支作为远程分支推送到原点，我以某种方式将其推回原点/开发。所以，我们现在有：

develop (A)- (D1) - (D2) -      -      (M1)
         \ - (F1) - (F2) - (F3) - (F4) /

我们还不想要的。由于在这一天只有我的自己和另一个开发人员，我登录到原始主机并将开发头部操作回D2提交并将我的功能分支回到F4。我让我的同事在我做完这件事之前不要拉，并且因此认为一切都很顺利。

（实际上我克隆了原始仓库，在当地更换了头部，然后将它们强行推回上游。我实际上并不记得确切的命令，但结果是所需的回购，就我而言可以看到。）

我忘记的是，我们的持续集成系统正在进行常规拉动并设法获得合并头的副本。一个星期后，我注意到了一些来自原始主机的巡航控制提交，并感觉不舒服。果然它正在将原点开发头部合并到其本地的“功能分支合并”回购中。

所以我们现在的情况有点像这样：

Cruisecontrol repo：

      (from origin/develop)            (C1) - (C2) - (C3)
develop (A)- (D1) - (D2) -      -      (M1) \ (M2) \ (M3)
         \ - (F1) - (F2) - (F3) - (F4) /

Origin repo：

develop (A)- (D1) - (D2) - (C1) - (C2) - (C3) 
         \ - (F1) - (F2) - (F3) - (F4)

C1和C2是由具有“更正”回购的开发人员（即在我的头部操作以撤消我的初始错误之后）进入原始仓库的提交，而M2和M3是现在巡航控制回购的合并提交不得不做。

现在我做了一些真的愚蠢的事情。我在巡航控制源回购中“git push”。所以我们的“原点”回购现在有M1合并，介入的M2和M3合并。

我再一次让我的同事不要拉扯一会儿。但是，我的git-foo不够强大，无法在原始仓库中解除Mx和Cx的相互提交，并将其恢复到应有的状态。

我认为我需要用HEAD ^（x）和HEAD~（y）做一些聪明的事情，但这是一个难以解释的情况，因此很难谷歌。

欢迎所有建议;我有一个每晚备份的repo运行，可能只是从那恢复，并让每个人从今天重新推动他们的提交，但我想知道这种类型的分支纠缠是否可能。

我想我应该能够在上面的原始图中找到原始仓库，并且巡航控制仓库被删除并重新克隆，并且M系列提交准备好在原始仓库中进行垃圾收集。 / p>

谢谢！

Answer 1

所有使用相同哈希的git中的提交都是相同的（历史也是如此），因此您应该能够在源和CI存储库中使用相同的命令（假设develop已签出：

# on the current branch:
git reset --hard C3
# on your feature branch:
git branch -f feature F4

git push默认情况下不应强制推送，并且您没有在问题中说明CI -> origin推送发生的位置，所以我假设这是一个快速推送（默认情况下））

对于未来我建议您的CI存储库执行git fetch + git reset --hard origin/develp，除非您希望将您的分支合并在一起（可能只有CI回购中存在的提交）

从存储库中删除不正确的合并

1 个答案: