无法根据其他用户的分支贡献重新定位

Question

我有一个问题，将主要的开发分支master重新定位到我的特性分支crm-feature。

我正在尝试使用正常的git rebase master crm-feature方法来完成这一任务。

当我这样做时，我会发现，当每一次提交都变成冲突时，我就到达了重基的某个点。

查看Github中的提交列表，我看到了我的所有提交(由我编写)，然后从其他人那里提交，那么我的所有提交似乎都是出于某种原因重新创建的。所有这些提交显示如下：

​

​

因此，从顶部的最新到最老的提交日志如下所示：

• 来自其他贡献者piccolax00的提交
• 来自其他贡献者piccolax00的提交
• 我编写的所有与piccolax00用户一起提交的提交都与上面的图像一样
• 来自其他贡献者的提交
• 我最初的承诺

因此，总之，我不明白piccolax00用户的提交来自何处，以及如何绕过它们，因为它们似乎是阻止我将分支重新部署到master的原因。这个分支是在我度假的时候工作的，在我离开之前，我所有的提交都在上面，因为我定期地在master上重新定位，给我来自主开发分支的最新代码，同时每次都在顶部重放我的工作。

我不确定这个分支是否已经被piccolax00用户重新定位了，如果是这样的话，我的选择是什么？

Answer 1

我将发布这篇文章，因为我最终被建议采取一种与@Cup蛋糕提供的方法略有不同的方法。希望这能对未来的人有所帮助。

在命令方面，我做了以下工作：

# made a backup of the branch incase I screw it up during the rebase
git checkout -b crm-feature-branch-original crm-feature-branch

# Rebase my branch onto master and replay my commits on top
git rebase -i crm-feature-branch master

在交互式重基期间，我随后删除了带有已复制的提交的行。我可以通过查看Github中的散列来判断哪些提交要删除，而不是pick。

我有一些冲突，但他们的期望，在任何地方都不接近我最初的数量。

Answer 2

考虑到所提供的信息，我将对如何解决你的问题进行有教养的猜测。

警告：此解决方案涉及重写存储库的历史，如果您不小心，这可能会导致数据丢失。在继续之前对存储库进行备份。

在Git中进行备份回购的最简单方法是简单地克隆另一个本地回购，并在出现问题时从备份中恢复。

(可能)储存库的状态

从您的描述来看，您的存储库和协作者的状态看起来如下所示：

# Collaborator history
aaa - ooo - AAA - bb

# Your history
aaa - ccc

哪里

1. a代表您的提交，
2. o表示来自其他用户的提交，
3. A表示重写的提交(基于以前的a提交)，
4. b表示piccolax00 00的提交，并且
5. c代表你的新提交，你还没有推进到共享上游回购。

一个解决方案

假设上面的内容是正确的，并且提交o还没有被重写(也就是说，A是唯一的重写提交)，那么您可以使用的一个解决方案是使用硬重置和对历史片段的选择性重基来重建正确的历史。

拼接你的合作者的分支

首先，我们将从您的协作者分支的本地副本中拼接出A提交(我们将称之为piccolax00)，

1. 开始在历史上最近的o提交中创建分支oldBase，以及在最近的A提交时创建分支oldBase， piccolax00 git分支newBase o git分支oldBase A
2. 接下来，将b提交系列重新定位到newBase分支(即o提交)， git重基--转到newBase oldBase piccolax00上 您可能需要重新解决可能发生的冲突。

执行上述操作后，假设任何冲突都已顺利解决，那么您的协作者的piccolax00分支将如下所示，

aaa - ooo - bb

作为一个健全的检查，这也是一个好主意，将这一新的历史与旧的历史

git diff piccolax00@{1}

在执行重基之前，piccolax00@{1}引用piccolax00分支的状态。如果piccolax00和piccolax00@{1}顶端的代码状态相同，那么重基没有在代码中引入任何错误。

把你的新承诺拼接在最上面

理论上，我们执行的早期步骤恢复了您的上游分支的“正确”历史，因此执行正常的重基应该会使您的分支与它同步，

git checkout crmpicco
git rebase piccolax00

你的历史就会变成这样，

aaa - ooo - bb - ccc

然后，您需要强制将这个新历史推到上游，因为您已经重写了相当多的提交，这样它们就不再具有与以前相同的sha ID。

警告：要非常小心地使用武力，重写共享历史。如果您的其他合作者已经为piccolax00推动的旧的共享历史添加了提交，那么他们将需要将自己的本地版本的共享历史与您正在推送的内容同步(可能是通过更多的重基)。

这就是为什么重写共享历史经常遭到反对的原因，对于一个项目的贡献者来说，如果它做得不正确的话，从它恢复过来可能是很费时的。

无论如何，如果您确定要继续推进重写的共享历史记录，则执行

git push -f upstream crmpicco

其中upstream是远程共享回购，而crmpicco是您想要推动的分支。

其他解决方案

以上解决方案完全有可能解决不了您的问题。如果没有更多的信息，我真的帮不了你，但是如果你被困了，你可以像托瑞克建议那样做，调查--fork-point是否会帮助你，

寻找“从上游重新基地恢复”。Git是新的(ish，2.0左右)--分叉点计算很有帮助。

其他资源

• Jan Krüger的官方Git文件镜子