Git rebase补丁文件在错误的地方

Question

我不确定这是git rebase的有意和已知的操作，或者如果我发现问题。我已经使用lorem ipsum将其复制到公共存储库中。 （https://github.com/drewclauson/git-rebase-example）

如果我有两段代码几行完全相同（see lorem ipsum.txt），则会出现此问题。理想情况下，代码将被重构以保持干燥，但我不知道同一文件中存在重复代码。

branch1有一个承诺master没有，反之亦然，所以我将branch1重新编号为master。

branch1'schange is adding a line between lines 23 and 24。 （“Test add a line of code”）

master'schange is editing line 23。 （插入23行上的“NEW TEXT”）

当我将branch1重新设置为master时，从branch1's提交的更改得到patched in between lines 8-9而不是第24-25行。

我不太了解git的操作，但我假设它与应该添加24和25之间的行的提交的上下文有关？基本上，它希望根据前后的线条进行修补，并且由于文件的前面有相同的代码，它只是在不考虑线数的情况下抛出修补程序？还是有我失踪的东西？

谢谢，我仍然是一个相对新手git，所以它可能是，我只是不明白的东西。

Answer 1

正如您怀疑的那样，Git会找到匹配的上下文并将更改应用到它。通常如果rebase成功而没有冲突，一切都很好，但有时候不会。总是根据需要验证结果并输入fixup。

理想情况下，你不会有这种重复来让Git跳起来，但还有其他的方式可能导致在成功的rebase之后很难避免的提交失败。例如，假设我们有一个分支，它在一些函数foo()中添加了一个使用变量x的代码块。现在想象一下，有人决定x不是一个描述性名称，并将其重命名为foo_counter。如果我们将分支重定位到master上，那么即使结果提交将无法编译，我们的代码的文本合并也很有可能会成功（因为我们指的是从未声明的变量）。在这种情况下，我们需要修复重新承诺使用foo_counter而不是x。再次，总是验证rebase的reslt。

这提示了与合并相比，重新绑定的缺点之一，而这在新的Git用户中往往会丢失。合并保留了原始分支上的提交，因此只需要验证最终的合并提交。但是，对于重定位，每个重新提交的提交都必须进行测试，以避免降低存储库的完整性。通常情况下，重新分配的分支将被固定，并在顶部进行额外的提交，使中间提交处于不可测试状态。即使最终结果看起来没问题，也可能发生这种情况。这看起来可能并不重要，但如果您曾经使用过Git的bisect，那么您将会体会到可测试的历史记录。并不是说这不能通过重新组装来实现，而只需要更多的工作。