Git rebase 补丁文件在错误的地方
Git rebase patches file in the wrong place
我不确定这是否是 git rebase 的预期和已知操作，或者我是否发现了问题。我已经使用 lorem ipsum 在 public 存储库中复制了它。 (https://github.com/drewclauson/git-rebase-example)
当我有两段代码在几行中完全相同 (see lorem ipsum.txt) 时，就会出现此问题。理想情况下，代码将被重构以保持 DRY，但我不知道同一个文件中存在重复代码。
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 的新手，所以可能我只是不太了解它。
如您所料，Git 找到匹配的上下文并将更改应用到它。通常，如果 rebase 在没有冲突的情况下成功，则一切都很好，但有时并非如此。始终根据需要验证结果和 fixup。
理想情况下，您不会让这种重复绊倒 Git，但还有其他方法可以在 "successful" 变基后以更难避免的破坏提交结束。例如，假设我们有一个分支，它添加了一个代码块，在某个函数 foo() 中使用变量 x。现在假设有人决定 x 不是一个描述性名称，并在 master 上将其重命名为 foo_counter。如果我们将我们的分支变基到 master 上，我们的代码的文本合并很可能会成功，即使生成的提交将无法编译（因为我们指的是一个从未声明过的变量）。在这种情况下，我们需要修复重新提交使用 foo_counter 而不是 x。同样，始终验证变基的结果。
这暗示了与合并相比，变基的缺点之一，新 Git 用户经常忽略这一点。合并会保留原始分支上的提交，因此只需要验证最终的合并提交。但是，对于变基，必须测试每个变基提交以避免降低存储库的完整性。通常，重新设置分支的分支会在顶部进行额外的提交，从而使中间提交处于无法测试的状态。即使最终结果看起来不错，也会发生这种情况。这可能看起来并不重要，但如果您曾经使用过 Git 的 bisect，您会很高兴拥有可测试的历史记录。并不是说这不能通过变基来实现，它只是需要更多的工作。
我不确定这是否是 git rebase 的预期和已知操作，或者我是否发现了问题。我已经使用 lorem ipsum 在 public 存储库中复制了它。 (https://github.com/drewclauson/git-rebase-example)
当我有两段代码在几行中完全相同 (see lorem ipsum.txt) 时，就会出现此问题。理想情况下，代码将被重构以保持 DRY，但我不知道同一个文件中存在重复代码。
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 的新手，所以可能我只是不太了解它。
如您所料，Git 找到匹配的上下文并将更改应用到它。通常，如果 rebase 在没有冲突的情况下成功，则一切都很好，但有时并非如此。始终根据需要验证结果和 fixup。
理想情况下，您不会让这种重复绊倒 Git，但还有其他方法可以在 "successful" 变基后以更难避免的破坏提交结束。例如，假设我们有一个分支，它添加了一个代码块，在某个函数 foo() 中使用变量 x。现在假设有人决定 x 不是一个描述性名称，并在 master 上将其重命名为 foo_counter。如果我们将我们的分支变基到 master 上，我们的代码的文本合并很可能会成功，即使生成的提交将无法编译（因为我们指的是一个从未声明过的变量）。在这种情况下，我们需要修复重新提交使用 foo_counter 而不是 x。同样，始终验证变基的结果。
这暗示了与合并相比，变基的缺点之一，新 Git 用户经常忽略这一点。合并会保留原始分支上的提交，因此只需要验证最终的合并提交。但是，对于变基，必须测试每个变基提交以避免降低存储库的完整性。通常，重新设置分支的分支会在顶部进行额外的提交，从而使中间提交处于无法测试的状态。即使最终结果看起来不错，也会发生这种情况。这可能看起来并不重要，但如果您曾经使用过 Git 的 bisect，您会很高兴拥有可测试的历史记录。并不是说这不能通过变基来实现，它只是需要更多的工作。