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