git rebase 的替代方案

Question

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

我做了以下事情：

1. git checkout testBranch
2. git fetch origin
3. git rebase origin/Master

我遇到了几个冲突，我正在使用合并工具（kdiff3）手动解决它，并说明要使用哪个已删除或修改的文件等...

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

我是否以正确的方式做这件事？

这是这种情况的唯一方法吗？或者有什么其他有效的方法？

Answer 1

您可以改用合并。

的优点merge：必须解决累积的不兼容更改仅在当前最终状态testBranch和当前状态之间master（尽管冲突的位置在行号方面可能相同），而不是testBranch从新的提示重新应用每个提交master（这是如何rebase工作的）。缺点merge：历史图变得更复杂，有些人不喜欢这种复杂的图，尤其是那些从具有简单树状历史图的“遗留”VCS 迁移而来的图。

有时像这样的工具git rerere 可能会有所帮助，尤其是在处理一组重复性冲突时。但这肯定不是灵丹妙药。

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

通常，将庞大的功能分支拆分为较小的部分并尽快将这些更改推回上游会有所帮助。因此，您的同事会使用您的代码和方法，而不是发明他们自己的 [冲突] 方法，因此对所有各方来说，合并/重新定位都会更简单。

在您的项目中使用强制性同行代码审查系统也很有用，即使是在功能分支中的提交也是如此。现在我有点怀疑人类仅仅通过盯着它来追踪复杂代码中可能的错误的能力。但至少所有参与特定代码位置开发的人员都知道提议的更改，并且可以协调不同分支的工作。

Answer 2

不，没有变基的替代方法。就是这样。经验教训：尽早变基，并经常变基。落后于你的提交意味着你迟早会浪费很多时间。两年前，我编写并合并了一个包含 200 个提交的功能分支，该分支是在六个月的时间内开发的。我不知道在这六个月中合并了多少提交。但我敢肯定，它们的数量也有数千个。如果我等到我完成我的功能分支，并尝试重新设置基础，我会遇到大麻烦。但我每天都重新定位，最终的合并结果是一个又大又肥的汉堡。

如果您的功能分支中的大约一百个提交可以在逻辑上分成小块，则可能将 rebase 分成多个阶段。如果您的功能分支的 100 个提交中有几个主要检查点，并且在每个点您的功能分支都是功能齐全且可测试的，您可以考虑仅将所有提交都提交到检查点，然后只对这些提交进行 rebase，然后测试它们. 然后，一旦你测试了你的初始提交块在 rebase 之后工作，继续和 rebase 提交直到下一个检查点。

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

但是请注意，要使其正常工作，您必须完美地跟踪功能分支上的所有提交；哪些已经重新定位，哪些没有。