Git: 为什么rebase会导致冲突而merge不会？
Git: Why does rebase result in conflicts while merge does not?
我可能没有得到正确的东西，但谁能向我解释为什么 git rebase 会导致冲突，而 git merge（同一分支）不会？
据我所知，git rebase 将其他分支的提交放在我当前分支上的提交之前，而 git merge 将相同的提交应用于我的分支补丁，对吧？ diff 是不是不一样，虽然可能是颠倒的？不知道为什么用其他提交修补我的分支不是问题，而用我的提交修补另一个分支是。
在变基期间，您将某个分支的所有提交应用到另一个分支之上。这些提交之一可能存在您在后续提交中解决的冲突。因此，合并操作没有冲突，而变基导致中间冲突。
另请参阅 git rerere，它允许您自动解决您已经解决的冲突。
我发现有时我的问题仍然得到赞成票。让我为那些不理解当前选择的答案的人解释一下，因为我第一次阅读时肯定不理解。
假设您有分支 master，其中提交了 A、B 和 C.
然后从提交 C 创建一个新分支 mybranch。你提交，你得到提交 D 和 E.
与此同时，其他人在 master 上提交 F 和 G。
master 看起来像这样：A B C F G，而 mybranch 看起来像这样：A B C D E.
现在你有两个合并策略：
合并
在 mybranch 上输入 git merge master。它需要来自 master 的所有提交，而您在 mybranch - F 和 G 上没有。它首先将 F 合并到您的 E 之上（mybranch 的最后一次提交），然后将 G 合并到 F.
之上
最终结果：A B C D E F G。尽管这些字母的顺序相同，但提交并未按时间顺序完成（或可能未完成），因为实际上 F 和 G 已经（或可能已经）在 D 和 E。在这种情况下，您也会看到合并提交。
变基
在 mybranch 上输入 git rebase master。它从 master 获取所有在 mybranch - F 和 G 上没有的提交，并将它们放在当前分支的顶部，使其处于以下状态master 当前在（因为您从 master 分支，现在获得了自分支以来在 master 上完成的所有提交）。然后它接受你的第一次提交 - D - 并将它合并到 G 之上（最后一次提交是在 master 上完成的）。然后它将 E 放在 D 之上。
最终结果：A B C F G D E。看起来好像没有分支被拆分 master，如果 master 是一个连续的工作，因为你有点说 "I want my branch to look as if it was just split off master and then my work was put on top of it"。这相当于签出 master（现在 A B C F G），创建一个新分支 mybranch，然后添加您的提交（A B C F G D E）。
为什么变基可能会导致冲突而合并不会。
不深入细节，我们只是说，在 mybranch 的 E 之上合并 master 的 F 可能不会导致冲突，但合并 mybranch 的 D 到 master 的 F 可能。这实际上取决于更改了哪些代码，以及它是否与之前的提交兼容。两种情况都可能出现合并冲突。
我可能没有得到正确的东西，但谁能向我解释为什么 git rebase 会导致冲突，而 git merge（同一分支）不会？
据我所知，git rebase 将其他分支的提交放在我当前分支上的提交之前，而 git merge 将相同的提交应用于我的分支补丁，对吧？ diff 是不是不一样，虽然可能是颠倒的？不知道为什么用其他提交修补我的分支不是问题，而用我的提交修补另一个分支是。
在变基期间，您将某个分支的所有提交应用到另一个分支之上。这些提交之一可能存在您在后续提交中解决的冲突。因此，合并操作没有冲突，而变基导致中间冲突。
另请参阅 git rerere，它允许您自动解决您已经解决的冲突。
我发现有时我的问题仍然得到赞成票。让我为那些不理解当前选择的答案的人解释一下，因为我第一次阅读时肯定不理解。
假设您有分支 master，其中提交了 A、B 和 C.
然后从提交 C 创建一个新分支 mybranch。你提交，你得到提交 D 和 E.
与此同时，其他人在 master 上提交 F 和 G。
master 看起来像这样：A B C F G，而 mybranch 看起来像这样：A B C D E.
现在你有两个合并策略：
合并
在 mybranch 上输入 git merge master。它需要来自 master 的所有提交，而您在 mybranch - F 和 G 上没有。它首先将 F 合并到您的 E 之上（mybranch 的最后一次提交），然后将 G 合并到 F.
最终结果：A B C D E F G。尽管这些字母的顺序相同，但提交并未按时间顺序完成（或可能未完成），因为实际上 F 和 G 已经（或可能已经）在 D 和 E。在这种情况下，您也会看到合并提交。
变基
在 mybranch 上输入 git rebase master。它从 master 获取所有在 mybranch - F 和 G 上没有的提交，并将它们放在当前分支的顶部，使其处于以下状态master 当前在（因为您从 master 分支，现在获得了自分支以来在 master 上完成的所有提交）。然后它接受你的第一次提交 - D - 并将它合并到 G 之上（最后一次提交是在 master 上完成的）。然后它将 E 放在 D 之上。
最终结果：A B C F G D E。看起来好像没有分支被拆分 master，如果 master 是一个连续的工作，因为你有点说 "I want my branch to look as if it was just split off master and then my work was put on top of it"。这相当于签出 master（现在 A B C F G），创建一个新分支 mybranch，然后添加您的提交（A B C F G D E）。
为什么变基可能会导致冲突而合并不会。
不深入细节，我们只是说，在 mybranch 的 E 之上合并 master 的 F 可能不会导致冲突，但合并 mybranch 的 D 到 master 的 F 可能。这实际上取决于更改了哪些代码，以及它是否与之前的提交兼容。两种情况都可能出现合并冲突。