Git在错误的位置重新建立补丁文件

Question

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

当我有两行代码对于几行完全相同时，就会发生此问题（ 请参阅lorem ipsum.txt ）。 理想情况下，将代码重构为保持DRY，但我不知道同一文件中存在重复的代码。

branch1提交了master没有的提交，反之亦然，所以我将branch1重新branch1到master 。

branch1's 更改是在第23和24行之间添加了一条线 。 （“测试添加一行代码”）

master's 更改是编辑第23行 。 （在第23行插入“ NEW TEXT”）

当我将branch1 master ，从branch1's提交branch1's更改被修补在8-9行之间，而不是24-25 行之间。

我对git的操作了解不多，但是我假设它与应该在24到25之间添加一行的提交上下文有关？ 基本上，它想基于前后的行进行修补，并且由于文件中较早的代码相同，因此它只是在不考虑行号的情况下将修补程序扔在那里了？ 还是我想念的东西？

谢谢，我还是git的新手，所以可能我只是不了解它。

Answer 1

如您所怀疑，Git会找到匹配的上下文并将更改应用于它。 通常，如果重新建立成功而没有冲突，那么一切都会很好，但有时不会。 始终验证结果并根据需要进行修复 。

理想情况下，您不必进行重复操作以使Git跳闸，但是还有其他一些方法很难避免在“成功”重新建立基础之后导致提交失败。 例如，假设我们有一个分支，该分支在某些函数foo()中添加了一个使用变量x的代码块。 现在，假设有人认为x不是描述性名称，然后将其重命名为foo_counter上的foo_counter 。 如果我们将分支基于master，那么即使最终的提交将无法编译，代码的文本合并很有可能会成功（因为我们引用的是从未声明的变量。）在这种情况下，我们需要修复重新提交以使用foo_counter而不是x承诺。 同样，请始终验证变基的分辨率。

与新的Git用户经常丢失的合并相比，这暗示了重新基准化的缺点之一。 合并会将提交保留在原始分支上，因此仅需要验证最终的合并提交。 但是，使用rebase时，必须测试每个基于recommit的提交，以避免降低存储库的完整性。 通常，将用一个额外的提交来修复一个重新建立基础的分支，使中间的提交处于不可测试的状态。 即使最终结果看起来不错，也可能发生这种情况。 这看起来似乎并不重要，但是如果您曾经使用过Git的bisect，那么您将拥有可测试的历史，将不胜感激。 并不是说重新部署无法实现这一点，而是需要做更多的工作。