接着git學習筆記(二)學習,今天學習下git分支管理。
1.創建合併分支
默認創建的git目錄只有master一個分支,現在我們創建dev分支,然後切換到dev分支:
$ git checkout -b dev
git checkout命令加上-b參數表示創建並切換,相當於以下兩條命令:
$ git branch dev
$ git checkout dev
然後,用git branch命令查看當前分支:
git branch命令會列出所有分支,當前分支前面會標一個*號。
然後,我們就可以在dev分支上正常提交,比如對readme.txt做個修改,加上一行:
Creating a new branch is quick.
然後提交:
現在,dev分支的工作完成,我們就可以切換回master分支:
git checkout master
切換回master分支後,再查看一個readme.txt文件,剛纔添加的內容不見了!因爲那個提交是在dev分支上,而master分支此刻的提交點並沒有變:
在,我們把dev分支的工作成果合併到master分支上:
$ git merge dev
git merge命令用於合併指定分支到當前分支。合併後,再查看readme.txt的內容,就可以看到,和dev分支的最新提交是完全一樣的。
注意到上面的Fast-forward信息,Git告訴我們,這次合併是“快進模式”,也就是直接把master指向dev的當前提交,所以合併速度非常快。
當然,也不是每次合併都能Fast-forward,我們後面會講其他方式的合併。
合併完成後,就可以放心地刪除dev分支了:
刪除後,查看branch,就只剩下master分支了:
因爲創建、合併和刪除分支非常快,所以Git鼓勵你使用分支完成某個任務,合併後再刪掉分支,這和直接在master分支上工作效果是一樣的,但過程更安全。
小結
Git鼓勵大量使用分支:
查看分支:git branch
創建分支:git branch <name>
切換分支:git checkout <name>
創建+切換分支:git checkout -b <name>
合併某分支到當前分支:git merge <name>
刪除分支:git branch -d <name>
2.解決衝突
人生不如意之事十之八九,合併分支往往也不是一帆風順的。
準備新的feature1分支,繼續我們的新分支開發:
修改readme.txt最後一行,改爲:
在feature1分支上提交:
切換到master分支:
Git還會自動提示我們當前master分支比遠程的master分支要超前1個提交。
在master分支上把readme.txt文件的最後一行改爲:
提交:
現在,master分支和feature1分支各自都分別有新的提交,這種情況下,Git無法執行“快速合併”,只能試圖把各自的修改合併起來,但這種合併就可能會有衝突,我們試試看:
果然衝突了!Git告訴我們,readme.txt文件存在衝突,必須手動解決衝突後再提交。git status也可以告訴我們衝突的文件:
我們可以直接查看readme.txt的內容:
Git用<<<<<<<,=======,>>>>>>>標記出不同分支的內容,我們修改如下後保存:
再提交:
用帶參數的git log也可以看到分支的合併情況:
$ git log --graph --pretty=oneline --abbrev-commit
最後,刪除feature1分支:
小結
當Git無法自動合併分支時,就必須首先解決衝突。解決衝突後,再提交,合併完成。
用git log –graph命令可以看到分支合併圖。
3.分支管理策略
通常,合併分支時,如果可能,Git會用Fast forward模式,但這種模式下,刪除分支後,會丟掉分支信息。
如果要強制禁用Fast forward模式,Git就會在merge時生成一個新的commit,這樣,從分支歷史上就可以看出分支信息。
下面我們實戰一下–no-ff方式的git merge:
首先,仍然創建並切換dev分支:
修改readme.txt文件,並提交一個新的commit:
現在,我們切換回master:
準備合併dev分支,請注意–no-ff參數,表示禁用Fast forward:
$ git merge --no-ff -m "merge with no-ff" dev
因爲本次合併要創建一個新的commit,所以加上-m參數,把commit描述寫進去。
合併後,我們用git log看看分支歷史:
$ git log --graph --pretty=oneline --abbrev-commit
分支策略
在實際開發中,我們應該按照幾個基本原則進行分支管理:
首先,master分支應該是非常穩定的,也就是僅用來發布新版本,平時不能在上面幹活;
那在哪幹活呢?幹活都在dev分支上,也就是說,dev分支是不穩定的,到某個時候,比如1.0版本發佈時,再把dev分支合併到master上,在master分支發佈1.0版本;
你和你的小夥伴們每個人都在dev分支上幹活,每個人都有自己的分支,時不時地往dev分支上合併就可以了。
小結
Git分支十分強大,在團隊開發中應該充分應用。
合併分支時,加上--no-ff參數就可以用普通模式合併,合併後的歷史有分支,能看出來曾經做過合併,而fast forward合併就看不出來曾經做過合併。
4.Bug分支
軟件開發中,bug就像家常便飯一樣。有了bug就需要修復,在Git中,由於分支是如此的強大,所以,每個bug都可以通過一個新的臨時分支來修復,修復後,合併分支,然後將臨時分支刪除。
當你接到一個修復一個代號101的bug的任務時,很自然地,你想創建一個分支issue-101來修復它,但是,等等,當前正在dev上進行的工作還沒有提交:
並不是你不想提交,而是工作只進行到一半,還沒法提交,預計完成還需1天時間。但是,必須在兩個小時內修復該bug,怎麼辦?
幸好,Git還提供了一個stash功能,可以把當前工作現場“儲藏”起來,等以後恢復現場後繼續工作:
$ git stash
現在,用git status查看工作區,就是乾淨的(除非有沒有被Git管理的文件),因此可以放心地創建分支來修復bug。
首先確定要在哪個分支上修復bug,假定需要在master分支上修復,就從master創建臨時分支:
隨便修改一下readme.txt文件,然後提交
修復完成後,切換到master分支,並完成合並,最後刪除issue-101分支:
太棒了,原計劃兩個小時的bug修復只花了5分鐘!現在,是時候接着回到dev分支幹活了!
工作區是乾淨的,剛纔的工作現場存到哪去了?用git stash list命令看看:
工作現場還在,Git把stash內容存在某個地方了,但是需要恢復一下,有兩個辦法:
一是用git stash apply恢復,但是恢復後,stash內容並不刪除,你需要用git stash drop來刪除;
另一種方式是用git stash pop,恢復的同時把stash內容也刪了:
再用git stash list查看,就看不到任何stash內容了:
你可以多次stash,恢復的時候,先用git stash list查看,然後恢復指定的stash,用命令:
$ git stash apply stash@{0}
小結
修復bug時,我們會通過創建新的bug分支進行修復,然後合併,最後刪除;
當手頭工作沒有完成時,先把工作現場git stash一下,然後去修復bug,修復後,再git stash pop,回到工作現場。
5.Feature分支
軟件開發中,總有無窮無盡的新的功能要不斷添加進來。
添加一個新功能時,你肯定不希望因爲一些實驗性質的代碼,把主分支搞亂了,所以,每添加一個新功能,最好新建一個feature分支,在上面開發,完成後,合併,最後,刪除該feature分支。
現在,你終於接到了一個新任務:開發代號爲Vulcan的新功能,該功能計劃用於下一代星際飛船。
於是準備開發:
5分鐘後,開發完畢:
切回dev,準備合併:
$ git checkout dev
一切順利的話,feature分支和bug分支是類似的,合併,然後刪除。
但是,
就在此時,接到上級命令,因經費不足,新功能必須取消!
雖然白乾了,但是這個分支還是必須就地銷燬:
銷燬失敗。Git友情提醒,feature-vulcan分支還沒有被合併,如果刪除,將丟失掉修改,如果要強行刪除,需要使用命令git branch -D feature-vulcan。
現在我們強行刪除:
小結
開發一個新feature,最好新建一個分支;
如果要丟棄一個沒有被合併過的分支,可以通過git branch -D <name>強行刪除。
6.多人協作
當你從遠程倉庫克隆時,實際上Git自動把本地的master分支和遠程的master分支對應起來了,並且,遠程倉庫的默認名稱是origin。
要查看遠程庫的信息,用git remote:
或者,用git remote -v顯示更詳細的信息:
上面顯示了可以抓取和推送的origin的地址。如果沒有推送權限,就看不到push的地址。
推送分支
推送分支,就是把該分支上的所有本地提交推送到遠程庫。推送時,要指定本地分支,這樣,Git就會把該分支推送到遠程庫對應的遠程分支上:
$ git push origin master
如果要推送其他分支,比如dev,就改成:
$ git push origin dev
但是,並不是一定要把本地分支往遠程推送,那麼,哪些分支需要推送,哪些不需要呢?
master分支是主分支,因此要時刻與遠程同步;
dev分支是開發分支,團隊所有成員都需要在上面工作,所以也需要與遠程同步;
bug分支只用於在本地修復bug,就沒必要推到遠程了,除非老闆要看看你每週到底修復了幾個bug;
feature分支是否推到遠程,取決於你是否和你的小夥伴合作在上面開發。
總之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,視你的心情而定!
抓取分支
多人協作時,大家都會往master和dev分支上推送各自的修改。
現在,模擬一個你的小夥伴,可以在另一臺電腦(注意要把SSH Key添加到GitHub)或者同一臺電腦的另一個目錄下克隆:
當你的小夥伴從遠程庫clone時,默認情況下,你的小夥伴只能看到本地的master分支。不信可以用git branch命令看看:
現在,你的小夥伴要在dev分支上開發,就必須創建遠程origin的dev分支到本地,於是他用這個命令創建本地dev分支:
現在,他就可以在dev上繼續修改,然後,時不時地把dev分支push到遠程:
提交
你的小夥伴已經向origin/dev分支推送了他的提交,而碰巧你也對同樣的文件作了修改,並試圖推送:
推送失敗,因爲你的小夥伴的最新提交和你試圖推送的提交有衝突,解決辦法也很簡單,Git已經提示我們,先用git pull把最新的提交從origin/dev抓下來,然後,在本地合併,解決衝突,再推送:
合併有衝突,需要手動解決,解決的方法和分支管理中的解決衝突完全一樣。解決後,提交,再push:
因此,多人協作的工作模式通常是這樣:
- 首先,可以試圖用git push origin branch-name推送自己的修改;
- 如果推送失敗,則因爲遠程分支比你的本地更新,需要先用git pull試圖合併;
- 如果合併有衝突,則解決衝突,並在本地提交;
- 沒有衝突或者解決掉衝突後,再用git push origin branch-name推送就能成功!
如果git pull提示“no tracking information”,則說明本地分支和遠程分支的鏈接關係沒有創建,用命令git branch –set-upstream branch-name origin/branch-name。
這就是多人協作的工作模式,一旦熟悉了,就非常簡單。
小結:
查看遠程庫信息,使用git remote -v;
本地新建的分支如果不推送到遠程,對其他人就是不可見的;
從本地推送分支,使用git push origin branch-name,如果推送失敗,先用git pull抓取遠程的新提交;
在本地創建和遠程分支對應的分支,使用git checkout -b branch-name origin/branch-name,本地和遠程分支的名稱最好一致;
建立本地分支和遠程分支的關聯,使用git branch --set-upstream branch-name origin/branch-name;
從遠程抓取分支,使用git pull,如果有衝突,要先處理衝突。
資料鏈接:Git教程-分支管理