git 冲突

摘要 git
conflict 通常有三种 树冲突、内容冲突、逻辑冲突。
git 冲突

目录[-]

冲突情况

冲突处理

Git工作方法

• git branch working #建立一个自己的分支，如取名working

• git checkout working #确保使用的是工作分支

• git add .

• git commit -m"$1" -a #提交代码到本地，工作分支增加一个版本，这里的$1是运行脚本的第一个参数

• git checkout master git pull origin master #切换回默认分支，并将默认分支和中央最新版本合并

• git merge working #在本地合并你的这次修改到默认分支

• git push origin master #提交到中央版本库，接下来还是要切换回工作分支的

• git checkout working --force



冲突的产生

• 很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。

• 而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。

• git
pull会自动merge，repo
sync会自动rebase，所以git
pull和repo sync也会产生冲突。当然git
rebase就更不用说了

冲突的类型

树冲突

• 方法文件名修改造成的冲突，称为树冲突。

• 比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。

• $
git status

added by us: b.c

both deleted: origin-name.c

added by them: a.c

• 如果最终确定用b.c，那么解决办法如下：

• git rm a.c

git rm origin-name.c

git add b.c

git commit

• 执行前面两个git
rm时，会告警“file-name : needs merge”，可以不必理会。

•

• 树冲突也可以用git
mergetool来解决，但整个解决过程是在交互式问答中完成的，用d删除不要的文件，用c保留需要的文件。

• 最后执行git
commit提交即可。

逻辑冲突

• git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。

• 比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。

• 又比如，函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。

• 这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。

内容冲突

• 两个用户修改了同一个文件的同一块区域，git会报告内容冲突。我们常见的都是这种。

冲突情况

• 当我们merge还是pull完后如果有冲突的话就会出现下面这个状态
出现CONFLICT 冲突我们就必须去查看对应的文件而不是直接add . 再次commit，这样git会直接把两个冲突的文件合并，然后提交

冲突处理

• 当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。

• 比如当前在master分支，想把dev分支merge过来，结果产生了一个冲突，打开文件内容可以看到这么一个冲突：

• <<<<<<< HEAD • test in master • ======= • test in dev • >>>>>>> dev

• <<<<<<<标记冲突开始，后面跟的是当前分支中的内容。

• HEAD指向当前分支末梢的提交。

• =======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。

• >>>>>>>之后的dev是该分支的名字。

• 　　对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。

git 删除已经 add 文件

使用 git rm 命令即可，有两种选择

• git
rm --cached "文件路径"，不删除物理文件，仅将该文件从缓存中删除；

• git
rm --f "文件路径"，不仅将该文件从缓存中删除，还会将物理文件删除（不会回收到垃圾桶）。

Git工作方法

• git branch working #建立一个自己的分支，如取名working

• git checkout working #确保使用的是工作分支

• git add .

• git commit -m"$1" -a #提交代码到本地，工作分支增加一个版本，这里的$1是运行脚本的第一个参数

• git checkout master git pull origin
master #切换回默认分支，并将默认分支和中央最新版本合并

• git merge working #在本地合并你的这次修改到默认分支

• git push origin master #提交到中央版本库，接下来还是要切换回工作分支的

• git checkout working --force

转载自：http://my.oschina.net/u/1757458/blog/349827#OSC_h3_4