首先,一个用git 写代码,而且只有一个本地分支的情况下是不会又冲突的.
冲突可以说是两个分支的冲突.具体是两个已经提交的分支的相同文件相同位置的的不同操作进行了合并.
不会冲突的习惯是,修改文件之前先merge 别的分支.
我在master 分支上创建并提交一个文件,切换到新的b分支上是没有这个文件的.这说明分支之间是相互独立的.
通过git merge master 把master上新增的文件给merge 过来.这是不会又冲突的.0+x = x
如果我在新的分支b上把master 对应行的数据给改了,并提交.然后切换到master,我再git merge b -m 'from b' 也不会冲突,结果是被b分支的修改给覆盖了.
冲突的原因:
如果我切换到分支b ,修改了master 原本哪行的代码,提交.然后再切换到master.我不知道b修改了这个文件.我也修改这一行的代码,并提交.好了,"两个分支相同文件相同位置的的不同操作" 我这个时候就在master merge b 或在 b上merge master. 冲突!!! 不解决冲突是没法提交和切换到别的分支的. 反正这个冲突后的文件必须被改动一下.
自动合并:
上面冲突的原因大字体的句子改为,我不知道b修改了这个文件.我[我在我自己的代码上做了修改,b并没有动我代码]的代码,并提交,然后去合并b ,不会冲突,即便我没有先merge b.这种情况是自动合并.
如何解决冲突:
冲突发生的时候,最好能联系一下开发的人员,一起解决冲突.
一般情况下冲突后的文件会是:
<<<<<<<<HEAD
other code
========
your code
>>>>>>>>your branch name
解决的一般办法是:仔细对比,取综合的并集,就是尽量把所有不同的文件保留,共同的只留一份
个人的一点经验:多人协作开发的时候,如果出现了你没有改过的文件跟你冲突了,一定要去找到当事者,说清楚是如何冲突,然后协商解决,千万不要擅自拉别的分支去试图解决冲突,或找文件覆盖.同时记住,解决了之后,要add 和 commit 最后push.为保证万无一失,最后在冲突都解决之后,重启项目,特别是指服务器项目,保证至少不会有立即奔溃的现象发生.然后才去提交,push.
提交的时候,一定要保持清醒,先搞清楚自己要提交的文件之间的关系,然后再提交,这样才不会有文件缺失的问题,造成奔溃.
如果任务比较多,又建议开多个分支,分别进行开发.还是老话,一定要清楚自己在各个分支上做了什么,自己要提交的是什么.最好是能做个详细的笔记.好记性不如烂笔头.
最笨的办法:没有把握宁愿不要去提交生产机.
提交代码的时候不要走神,因为这是一个神圣的时刻.开发的时候你可以怎么测试都行,一旦上生产机,各种奇葩问题都会出现.