人为的制造文件差异，为什么 git rebase 不产生文件冲突提醒？

[huzhikuizainali]

实验思路：起点，master 分支 dev 分支的 ABC 文件完全一样，后续 dev 分支只修改 A 文件，其他文件不懂。master 分支，只修改 C 文件，增加 D 文件，其他文件不变。造成“没有任何一个文件是两个分支共同修改”的局面。同时两个分支的 A 文件和 C 文件又是有差别的！

实验过程如下： 1 、在工作区创建 ABC 三个 txt 文件。git add . git commit 使的 master 有第一个 commit

2 、git checkout -b dev 复制 master 分支到 dev 分支。此时两个分支内容相同

3 、停留在 dev 分支，修改 A 文件。然后 add commit ，使得 dev 分支有别 master 分支

4 、跳回 master 分支 修改 C 文件 ，然后 add commit ，使的 master 分支有别于 dev 分支，且分叉

5 、在 mster 分支，增加 D 文件。然后 add commit ，使的 master 分支领先 dev 分支两个版本 此时，master 分支的 A 文件和 dev 分支的 A 文件是不同的版本，两者有区别。但是这两个分支并没有共同修改过同一个文件。dev 分支只修改 A 文件。master 分支只修改 C 文件，增加 D 文件。

6 、跳到 dev 分支。然后 git rebase 。结果在两个分支 AC 文件有差异的情况下没有任何冲突警告！ 我停留在 dev 分支。 在工作区，我打开 A 文件查看。发现是 dev 修改后的 A 文件。我打开 C 文件，发现是 master 修改后的 C 文件。D 文件也在。（我觉得这个结果是不正常的！ git 为什么不询问用户就在 A 文件中“继承了”dev 分支的版本。同样的，为什么不询问用户就直接“继承”了 master 分支修改后的 C 文件？）

 我跳回 master 分支。在工作区，我打开 A 文件查看。发现是 master 的老版本 A 文件。C 文件是 master 修改后的 C 文件。D 文件也在 （我觉得这个结果是正常的）

下图是 rebase 以后的分支图和 commit 记录

[akaxiaok339]

你都没有修改同一个文件，哪来的冲突

[huzhikuizainali]

@akaxiaok339 你说的我知道，我的困惑你没理解。
1 、两个分支共同修改同一个文件，那必然有冲突。毫无疑问

2 、作如下场景假设：dev 分支的版本演进是依赖于“C 文件是初始版本这一基础”。结果 rebase 时新版本直接用 master 的 C 文件“替换”了 dev 分支的 C 文件，完全不通知 dev 分支的管理人，而这种替换很可能造成预料之外的结果。因此从代码版本管理的角度是不是应该做个冲突提示呢？一切工具都是为用户需求服务的对吧。

[whileFalse]

不然你 rebase / merge 的目的是什么呢？

如果你需要在 rebase/merge 之前对比所有修改，为什么不用 git diff 呢

[huzhikuizainali]

@whileFalse 谢谢回复
我顺着你这个思路考虑了一下。git diff 操作的时候是直接在后面附上两个版本的 commit sh1 么？现实工作中工作流程一般都是在 rebase 之前先 git diff 一下两个分支的最新版本么？

[besto]

没冲突为啥要提示？这就是 rebase 的意义，如果你用 merge 你还能得到更奇怪结果：
比如 master 分支修改 A 文件，产生 commit1 ，cherry-pick 到 dev 分支产生 commit1-1(commit msg 一模一样），在 dev 分支产生 commit2,然后 master merge dev 的改动，你会在 master 上同时看到 commit1 commit1-1 commit2(也就是你会看到 2 个一模一样的 commit ，但是一个 commit show 出来是空的）

[Hug125]

git 冲突的本质是对于相同文件同一行的更改，也就是在 merge 或 rebase 时，如果没有检测到对同一行的不同修改，就不会有冲突。
这大大降低了开发人员对代码的管理成本，不需要关心别人改动了而我没有去动的东西。