首页 > 代码库 > git 冲突
git 冲突
冲突的产生
? 很多命令都可能出现冲突，但从根本上来讲，都是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
git 冲突