git rebase的替代方案

我是git的新手。 比方说，我已经从远程分叉了一个本地存储库，它被称为localRepo。有两个分支Master和testBranch。testBranch向前提交100次，向后提交5000次。对testBranch进行了更改，但从未合并到Master。所以我想在我的分叉localRepo中将testBranch重设为master

我做了以下工作：

git checkout testBranch

git获取来源

git重新基准原点/主原点

我遇到了一些冲突，我正在使用mergetool（kdiff3）手动解决，并说明要使用哪个删除或修改的文件等

由于它大约落后5000次提交，是否有可能发生更多冲突？如果我像这样手动解决冲突，我想知道需要多少天！这将是非常乏味和不切实际的

我这样做对吗

---

这是这种情况下的唯一方法吗？或者任何其他有效的方法？

不，除了重新设置基础，没有其他选择。事实就是这样。经验教训：尽早重设基础，并经常重设基础。延迟你的承诺意味着你迟早会浪费很多时间。两年前，我编写并合并了一个200提交特性分支，它是在六个月的时间内开发的。我不知道在这六个月中有多少次提交被合并。但我相信他们也有数千人。如果我等到完成我的特性分支并尝试重新设置基址，我会遇到大麻烦。但我每天都会重新调整基准，最终的合并结果是一个又大又肥的汉堡

如果功能分支中的大约一百个提交在逻辑上可以划分为小块，那么可以将重基划分为多个阶段。如果在你的特征分支的百个提交中有几个主要检查点，并且在每个点上，你的特征分支是完全可操作的和可测试的，那么你可以考虑只将所有的提交都带到检查点，然后重新设置这些点，然后测试它们。然后，一旦测试了提交的初始块在重新设置基础后工作，继续并重新设置提交的基础，直到下一个检查点

当您一次对所有内容重新设置基址时，git只会在每次未能重新设置基址的提交时停止。至少通过这种方式，您可以更好地控制流程。您可以在预定的检查点处停止和暂停，并对重定基础的更改进行广泛的回归测试，然后继续

但是，请注意，要使其发挥作用，您必须完美地跟踪特性分支上的所有提交；哪一个已经重新设置了基础，哪一个没有重新设置基础。

您可以改为使用

merge

的优点是：只需解决

testBranch

的当前最终状态和

master

的当前状态之间累积的不兼容更改（尽管冲突位置在行号方面可能相同），而不是在

master

的新技巧上重新应用

testBranch

中的每个提交（这就是

rebase

的工作原理）。

合并的缺点

：历史图变得更加复杂，一些人不喜欢这样复杂的图，尤其是那些从“遗留”VCSE迁移过来的带有简单树状历史图的图

有时可能会有帮助，特别是当一个人处理一系列重复的冲突时。但这肯定不是一颗银弹

是的，遵循@SamVarshavchik的建议：最好定期跟踪上游变化，并在您的功能分支中与它们“保持一致”，而不是在一个阳光明媚的早晨发生数千行冲突。或者不是那么晴朗，或者不是一个早晨——事实上，这并不重要，因为一个人必须花费数小时、数天甚至数周的时间来安定下来

通常，它有助于将巨大的功能分支拆分为更小的部分，并尽快将这些更改推回到上游。因此，您的同事将使用您的代码和方法，而不是发明他们自己的[冲突]方法，因此合并/再平衡对于各方来说都将更简单

---

此外，在项目中使用强制对等代码审查系统也很有用，即使是在功能分支中提交。现在我有点怀疑人类是否有能力通过简单地观察复杂代码来追踪可能的错误。但是，至少所有参与开发特定代码位置的人员都知道建议的更改，并且能够协调不同分支机构的工作。

感谢您的见解！我会照山姆说的做。我已经发布了一个跟进问题。如果你也能看一看，那会很有帮助的。谢谢，山姆。这些信息对我很有帮助。我已经发布了一个后续问题。如果你也能看一看，那会很有帮助的。（）当功能分支与其他人共享时，情况如何？也就是说，它是公共的？再基地仍然是正确的方式吗？