我对吉特不熟悉。
比方说，我从远程在本地派生了一个存储库，它被称为localrepo。有两个分支master和testbranch。testbranch提前100次提交，落后5000次提交。对testbranch进行了更改，但从未合并到master。所以我想在分叉的localrepo中将testbranch重设为master。
我做了以下工作：git checkout testBranchgit fetch origingit rebase origin/Master
我遇到了一些冲突，我正在用mergetool（kdiff3）手动解决它，并说要使用哪个删除或修改的文件等等。
由于它落后了5000次提交，是否有可能发生更多的冲突？如果我像这样手动解决冲突，我想知道需要多少天！这将是非常乏味和不现实的。
我做的对吗？
这是这个场景的唯一方法吗？或者其他有效的方法？
最佳答案
不，没有其他的方法可以改变。就是这样。经验教训：尽早调整，经常调整。落后于你的承诺意味着你迟早会浪费很多时间。两年前，我编写并合并了一个200个commit特性分支，它是在六个月的时间里开发的。我不知道在这六个月里合并了多少个提交。但我相信他们也有成千上万的人。如果我等到我完成了我的功能分支，并试图重新定位，我会遇到大麻烦。但我每天都在减价，最终合并成了一个又大又胖的汉堡。
如果特性分支中的大约100个提交可以逻辑地划分为小块，那么可以将rebase划分为多个阶段。如果在功能分支的100个提交中有几个主要的检查点，并且在每一点上，功能分支都是完全功能性的和可测试的，那么您可以考虑将所有提交都只带到检查点，然后仅重新平衡这些提交，然后测试它们。然后，一旦您测试了提交的初始块在重新定位之后是否工作，就继续并重新定位提交，直到下一个检查点。
当您一次回扣所有内容时，git只会在每次未能回扣的提交时停止。至少这样你可以更好的控制整个过程。您可以在预定的检查点处停止并暂停，并对重新调整基准的更改进行广泛的回归测试，然后继续。
不过，请注意，要实现这一点，您必须完美地跟踪您的功能分支上的所有提交；哪些提交已被重新调整，哪些没有。