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