我可能没有得到正确的答案，但任何人都可以向我解释为什么getFragmentManager()会导致冲突，而git rebase（同一分支）却没有？
据我所知，git merge在我当前分支的提交之前将提交来自另一个分支，而git rebase接受相同的提交并将它们作为补丁应用于我的分支，对？ git merge然后不一样，虽然可能会逆转吗？不知道为什么用其他提交修补我的分支不是问题，而用我的提交修补另一个分支是。
答案 0 :(得分：7)
在rebase期间，您将某个分支的所有提交应用于另一个分支的顶部。其中一个提交可能存在您在后续提交中解决的冲突。因此，合并操作没有冲突，而rebase导致中间冲突。
另请参阅git rerere，它允许您自动解决已解决的冲突。
答案 1 :(得分：0)
我看到有时我的问题仍然受到反对。让我为那些不了解当前选择答案的人解释一下，因为我第一次阅读时肯定没有。
假设您的分支master包含提交A，B和C。
然后从提交C中创建一个新分支mybranch。您提交，并得到D和E的提交。
同时，其他人将F和G提交给master。
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在{{ 1}}和D。在这种情况下，您也会看到合并提交。
在E上，键入mybranch。它接受git rebase master-master和mybranch上您没有的所有F提交。然后，它将接受您的第一个提交-G-并将其合并到D的顶部（最后一个提交在G中）。然后，它取master并将其放在E的顶部。
最终结果：E。好像没有分支被master分离过，并且master是一个连续的工作，因为您说过“我希望我的分支看起来像是被master分离，然后将我的工作放在上面”。这等效于签出A B C F G D E（现在为master），创建新分支A B C F G，然后添加提交（mybranch）。
在此不做详细说明，而只是将A B C F G D E的{{1}}合并到master的{{1}}可能不会导致冲突，但可以将F的{{1}}合并到mybranch的{{1}}之上。它实际上取决于更改的代码以及是否与先前的提交兼容的更改。两种情况下都可能发生合并冲突。