摘要：通常我們工作時是這樣操作說一下使用做版本控制的時候的工作流程需要添加到版本庫中的文件就代表著所有文件除開了忽略掉的文件本次提交的備注將遠程的庫和本地的庫版本同步一下因為遠程庫可能發(fā)生了修改多人合作開發(fā)時這樣操作的前提是本地遠程都是同一

說一下使用 git 做版本控制的時候的工作流程

git add -A           #需要添加到版本庫中的文件 -A 就代表著所有文件(除開了 .gitignore忽略掉的文件)
git commit -m "本次提交的備注"
git pull            #將遠程的庫和本地的庫版本同步一下,因為遠程庫可能發(fā)生了修改(多人合作開發(fā)時)
git push          

這樣操作的前提是本地遠程都是同一個 master 分支上

以上操作前兩步通常不會碰到問題,最容易發(fā)生問題的是 git pull 這一步
因為多人開發(fā)時難免碰到同時修改了同一個文件,那么就會產生沖突
git 是根據(jù)文件每行發(fā)生的修改進行的判定的,如果同時對同一文件的同一行發(fā)生了修改,就卡死到這一步上了

我常用的是命令行和 phpstrom 中的版本控制工具,最推薦的是命令行操作,別的圖形界面也是調的命令行接口
直接學會git 的命令是學習成本最低的一種方式,一次學會到處可用啊!

命令行還有個強大的地方就是它的提示通常就是你解決問題的方法,照著提示打就行(要善用提示啊,別看見報錯就慌了)

我們做一個實驗,我自己的一個版本庫本地和遠程同時發(fā)生了修改,而且是操作的同一個文件,
我直接進行 git push操作

看到提示沒?提示中的 hint 中說了,向遠程庫中更新被拒,因為遠程有了修改而本地沒有(說白了就是沒同步),
這通常發(fā)生在另一個版本庫向遠程推送了相同的文件(就是兩個人在這個版本下同時操作了同一個文件),
提示中給出原因之后緊接著給出了解決辦法(e.g., "git pull ...")before pushing again,

我們按著它給的提示操作一下

通常如果兩個人之間的操作不發(fā)生沖突比如同時修改了同一個文件的同一行的情況下就會進入commit的
編輯界面了,但是我給他人為的造成一個錯誤,這個錯誤就是我們最常碰到的錯誤,合并沖突
看到提示中的最后一行了沒有?
Automatic merge failed; fix conflicts and then commit the result.
自動合并失敗了,請修復沖突并再次提交

如果文件很多我怎么去找到它?

一種是靠界面工具主動把錯誤推到你面前

另一種就是自己去找了

第一種方法坑爹的地方就是好多工具他給你提示就提示一次,你如果給關了就不會再提示了,但是該提交不上去的
還是提交不上去,而且如果是線上火速修復的時候你的編輯器是幫不到那么遠的
我們選第二種,肯定不是挨個文件去翻啊!會死人的

有一個很有用的命令

git status

標紅的文件都給你了,而且還給你了需要執(zhí)行的命令,你別假裝看不到啊!
當然這個時候直接git add && git commit會出事的,你還沒解決沖突呢!
我們去這個沖突文件中解決掉沖突本地能跑通了再提交,而且這個錯誤提示會指名文件路徑的,我這個沖突文件
因為正好是在項目的根目錄下才沒有的

打開這個文件我們看到如下的內容:

我這是在 phpstrom 中打開的文件,如果phpstrom 能讀取到你項目中的 .git/ 目錄是可以進行版本控制的
這里phpstrom 就幫你把沖突文件標紅了,多么醒目~當然這也是我們自己找的
如果文件內容特別多但是就一兩處沖突時我們直接搜索關鍵詞 HEAD或者<<<<<<<就行,你懂的...
被尖角號擴起來的就是沖突的地方,接下來就是保孩子還是保大人解決沖突的時候了,找到誰和你改的同一處代碼

什么?你說你找不到是誰?你沒看到代碼沖突塊下的 779833d952d8a6557b2e8eba3bd192ede5cb6ca0
這一段文字嗎?你先別激動,這個點還不適合開車,這個是提交的 commit-id,你每次提交都會產生的一個標識
要查看這到底是誰和我的代碼沖突了就執(zhí)行下面的命令

git log 779833d952d8a6557b2e8eba3bd192ede5cb6ca0

第一行就是你要的結果,
如果直接git log -p 就是列出所有的提交記錄 -p 就是顯示出修改的地方

沖突塊部分 HEAD就是你寫的代碼,下面的是別人寫的,去掉其中一個把那些標簽清理干凈,測試一下沒問題了
再git add && git commit && git pull && git push 這四連技好了,世界清凈了

這是我在 segmentfault 中給出的答案:

比如你從一個git log為1,2,3,4,5,6的遠程庫拉取到了本地,
另一個同事也拉取了同樣的代碼,而且你的同事先于你提交到遠程了,
此時遠程的版本是1,2,3,4,5,6,7_new,8_new,
而你當前只是本地的版本1,2,3,4,5,6,7_local,8_local,9_local
從這里你就能看出你前一部分和遠程的一樣,后一部分和遠程的不一樣,
這個時候你不能正常推送上去的,如果你采取git push origin master --force
那么遠程的版本就變成了1,2,3,4,5,6,7_local,8_local,9_local
之前你同事推送的7_new,8_new這兩次推送被覆蓋了,這不是大家想要的情況
因此需要git pull來將本地的版本合并成樣
1,2,3,4,5,6,7_new,7_local,8_local,8_new,9_local,10_commit_merge
遠程和本地的排序是按當時 commit 的時間來排的,最后一個10_commit_merge就是你本地和遠程合并的標志,最后你推送到遠程倉庫的應該也是這個,
因為你們操作的是同一個庫始終要保持代碼的同步,所以一旦版本庫發(fā)生改動同一分支下的所有人都要跟著去同步他,因為各開發(fā)各的直接往上推 git 還沒智能到幫你處理沖突的地步

比如我有兩個分支

* alpha
  dev

我只要 dev 中的某幾個文件, 比如 README.md 和 LICENSE.md, 那么我就

git checkout dev /path/to/README.md /path/to/LICENSE.md

就會拉取 dev 分支中的這幾個文件覆蓋到 alpha 分支上, 注意拉取的文件會強制覆蓋, 然后你 git diff 一下這幾個文件看有沒有問題, 直接git commit && git pull && git push 一套帶走就行

答案鏈接
博客原文