博客探讨了Git分支在合并过程中的工作原理，指出合并可能导致冲突。文章通过示例说明，当master分支和dev分支合并时，最终的提交G会包含两者的内容，可能需要解决冲突。在解决冲突后，两个分支可以继续独立发展，如master分支的H和dev分支的I。此过程强调了分支管理和合并策略的重要性。
Git
在学习merge的时候产生了不理解的地方
分支是用来标记特定代码的提交，每一个分支通过SHA1sum值来标识，所以对分支的操作是轻量级的，你改变的仅仅是SHA1sum值。
如下图所示，当前有2个分支，A,C,E属于master分支，而A,B，D,F属于dev分支。
A----C----E（master）
B—D---F(dev)
1
2
3
它们的head指针分别指向E和F，对上述做如下操作：
git checkout master //选择or切换到master分支
git merge dev //将dev分支合并到当前分支(master)中
1
2
合并完成后：
A—C---E—G(master)
\ /
B—D---F（dev）
1
2
3
现在ABCDEFG属于master，G是一次合并后的结果，是将E和Ｆ的代码合并后的结果，可能会出现冲突。而ABDF依然属于dev分支。可以继续在dev的分支上进行开发:
A—C---E—G---H(master)
\ /
B—D---F—I（dev)
这是在博客园中看到的分支合并的介绍，觉得很有道理
但是对照软构ppt中的解释，产生了疑惑
综合考虑，由于在分支合并时，会产生冲突，所以我认为，分支合并要以前一种情况为准，即两个版本的commit要合并为一个版本
扫一扫
941
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
