Git merge and rebase aim is the same, rejoining two branches together in order to get a single up to date branch.
When trying the Merge and Rebase tool in Android Studio(which uses git commands obviously), I'm getting different results.
Merge - show me real conflicts between many files.
Rebase - Show only 1 conflicted file.
I know that merge and rebase are two completely different commands(rebase changes the HEAD of the feature branch, and adding the new commits on top of it(keeping commits history log) while merge tries to merge the HEADS of both branches). But it doesn't make sense that they return different results. I mean, conflict is a conflict no? If user A and user B changed the same line so it always should conflict that line, no matter if you use merge or rebase?
答案 0 :(得分：0)
也许这取决于分支点之后你有多少次提交。
如果您有多个提交，git merge会立即向您显示所有冲突，git rebase会向您显示每次提交的冲突。
假设您遇到这种情况：
master A --- B --- C <- HEAD of master
\
branch --- D --- E <- HEAD of branch
如果您在E并且执行了git merge master，git会向您显示所有冲突并要求您在创建合并提交之前修复。
如果您执行git rebase master，git将接管主人（C）然后应用您的提交D并显示要求修复的冲突（如果有）继续使用rebase。当您修复冲突并修改提交时，继续git rebase --continue，它将应用提交E并再次显示冲突。
答案 1 :(得分：0)
将rebase视为相反方向的合并。
如果方向不同，合并或重组在相同的冲突中停止是很自然的。
（这就是为什么你只在rebase期间看到1次冲突）。
rebase vs merge的结果很大程度上取决于实际的变化。如果更改在提交集之间是独立的，它们应该是相同的。
但是如果任何提交更改了先前提交更改的内容，那么顺序（merge vs rebase）可能会产生不同的结果/冲突。
示例
如果你是删除一行代码并重新绑定，并且文件的最后一个版本具有相同的周围行，该行可能会被删除而没有问题。
无论下面发生了什么变化，它都需要干净利落地使用＃34;
但是，如果合并并且合并区域中的代码发生了变化，删除该行可能会与其他更改发生冲突（即使合并提交的＆＃34;净结果＆＃34;与您工作的原始文件相同）上）。
解决方法
最好的方法是以交互方式git rebase -i master重新定位。这样你就可以影响＆＃34;您的rebase中的更改顺序，以便它们干净地应用或导致更少的冲突。
通常，您可能只想在将多个分支的更改集成到版本中时使用合并。因此，rebase和merge在功能上都有不同的目的＆＃34;。如果要将自己的本地更改附加到远程分支，并在您选择和混合其他人所做的更改时进行合并，则可以进行重新绑定。
请注意，合并和rebase都是＆＃34;欺骗＆＃34; - 他们更改提交的时间表，更改可能会产生副作用，具体取决于顺序。
（例如，如果一个人移除了一条线然后恢复了改变......而另一个人只是移除了这条线......是否应该移除该线？）
所以订单（rebase vs merge）很重要。