Git 合并和变基的目的是相同的，将两个分支重新连接在一起以获得一个最新的分支。
在 Android Studio 中尝试 Merge 和 Rebase 工具（显然使用 git 命令）时，我得到了不同的结果。
合并 - 向我展示许多文件之间的真实冲突。
变基 - 仅显示 1 个冲突文件。
我知道 merge 和 rebase 是两个完全不同的命令（rebase 更改功能分支的 HEAD，并在其之上添加新提交（保留提交历史日志），而 merge 尝试合并两个分支的 HEADS） .但是它们返回不同的结果是没有意义的。我的意思是，冲突就是冲突，不是吗？如果用户 A 和用户 B 更改了同一行，那么无论您使用合并还是变基，它总是应该与该行冲突？
【问题讨论】：
标签： git android-studio git-merge git-rebase
也许这取决于你在分支点之后有多少次提交。
如果您有多个提交，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 将接管 master (C) 然后应用您的提交 D 并显示冲突（如果存在）要求修复并继续进行 rebase。当您修复冲突并修改提交时，您继续使用git rebase --continue，它将应用提交E 并再次向您显示冲突。
【讨论】：
将 rebase 视为相反方向的合并。
如果方向不同，合并或变基很自然地会在不同的冲突处停止。
（这就是为什么你在变基期间只看到 1 个冲突）。
变基与合并的结果很大程度上取决于实际的变化。如果提交集之间的更改是独立的，则它们应该是相同的。
但是，如果任何提交更改了之前提交所更改的内容，那么顺序（合并与变基）可能会产生不同的结果/冲突。
示例
如果你例如删除一行代码并重新设置基准，并且文件的最后一个版本具有相同的周围行，该行可能会被删除而没有问题。
只要它“干净地应用”，不管下面发生了什么变化。
但是，如果您合并并且合并区域中的代码发生了更改，则删除该行可能会与其他更改发生冲突（即使合并提交的“最终结果”与您处理的原始结果相同）。
解决方法
最好的方法可能是交互式地变基git rebase -i master。通过这种方式，您可以“影响”您的变基中更改的顺序，以便它们干净地应用或导致更少的冲突。
通常，当您将来自多个分支的更改集成到一个版本中时，您可能只想使用合并。因此，rebase 和 merge 在功能上都有“不同的目的”。当您想将自己的本地更改附加到远程分支时，您可以 rebase，并在您选择和混合其他人所做的更改时合并。
请注意，merge 和 rebase 都是“作弊”——它们会更改提交的时间线，并且更改可能会根据顺序产生副作用。
（例如，如果一个人删除了一行，然后恢复更改......而另一个人只是删除了该行......是否应该删除该行？）
所以顺序（rebase vs merge）很重要。
【讨论】：