实验思路:起点,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 文件也在 (我觉得这个结果是正常的)
1
akaxiaok339 2023-05-30 16:10:11 +08:00
你都没有修改同一个文件,哪来的冲突
|
2
huzhikuizainali OP @akaxiaok339 你说的我知道,我的困惑你没理解。
1 、两个分支共同修改同一个文件,那必然有冲突。毫无疑问 2 、作如下场景假设:dev 分支的版本演进是依赖于“C 文件是初始版本这一基础”。结果 rebase 时新版本直接用 master 的 C 文件“替换”了 dev 分支的 C 文件,完全不通知 dev 分支的管理人,而这种替换很可能造成预料之外的结果。因此从代码版本管理的角度是不是应该做个冲突提示呢?一切工具都是为用户需求服务的对吧。 |
3
whileFalse 2023-05-30 16:21:24 +08:00
不然你 rebase / merge 的目的是什么呢?
如果你需要在 rebase/merge 之前对比所有修改,为什么不用 git diff 呢 |
4
huzhikuizainali OP @whileFalse 谢谢回复
我顺着你这个思路考虑了一下。git diff 操作的时候是直接在后面附上两个版本的 commit sh1 么?现实工作中工作流程一般都是在 rebase 之前先 git diff 一下两个分支的最新版本么? |
5
besto 2023-05-30 16:59:41 +08:00
没冲突为啥要提示?这就是 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 出来是空的) |
6
Hug125 2023-06-01 08:21:08 +08:00
git 冲突的本质是对于相同文件同一行的更改,也就是在 merge 或 rebase 时,如果没有检测到对同一行的不同修改,就不会有冲突。
这大大降低了开发人员对代码的管理成本,不需要关心别人改动了而我没有去动的东西。 |