4、git分支管理
一、分支的創建與合並
在版本回退裏,你已經知道,每次提交,Git都把它們串成一條時間線,這條時間線就是一個分支。截止到目前,只有一條時間線,在Git裏,這個分支叫主分支,即master
分支。HEAD
嚴格來說不是指向提交,而是指向master
,master
才是指向提交的,所以,HEAD
指向的就是當前分支。
一開始的時候,master
分支是一條線,Git用master
指向最新的提交,再用HEAD
指向master
,就能確定當前分支,以及當前分支的提交點:
每次提交,master
分支都會向前移動一步,這樣,隨著你不斷提交,master
分支的線也越來越長:
當我們創建新的分支,例如dev
時,Git新建了一個指針叫dev
master
相同的提交,再把HEAD
指向dev
,就表示當前分支在dev
上:
你看,Git創建一個分支很快,因為除了增加一個dev
指針,改改HEAD
的指向,工作區的文件都沒有任何變化!
不過,從現在開始,對工作區的修改和提交就是針對dev
分支了,比如新提交一次後,dev
指針往前移動一步,而master
指針不變:
假如我們在dev
上的工作完成了,就可以把dev
合並到master
上。Git怎麽合並呢?最簡單的方法,就是直接把master
指向dev
的當前提交,就完成了合並:
所以Git合並分支也很快!就改改指針,工作區內容也不變!
合並完分支後,甚至可以刪除dev
分支。刪除dev
分支就是把dev
master
分支:
真是太神奇了,你看得出來有些提交是通過分支完成的嗎?
下面開始實戰。
首先,我們創建dev
分支,然後切換到dev
分支:
1 $ git checkout -b dev 2 Switched to a new branch ‘dev‘
git checkout
命令加上-b
參數表示創建並切換,相當於以下兩條命令:
$ git branch dev $ git checkout dev Switched to branch ‘dev‘
然後,用git branch
命令查看當前分支:
1 $ git branch 2 * dev3 master
git branch
命令會列出所有分支,當前分支前面會標一個*
號。
然後,我們就可以在dev
分支上正常提交,比如對readme.txt做個修改,加上一行:
Creating a new branch is quick.
然後提交:
1 $ git add readme.txt 2 $ git commit -m "branch test" 3 [dev fec145a] branch test 4 1 file changed, 1 insertion(+)
現在,dev
分支的工作完成,我們就可以切換回master
分支:
1 $ git checkout master 2 Switched to branch ‘master‘
切換回master
分支後,再查看一個readme.txt文件,剛才添加的內容不見了!因為那個提交是在dev
分支上,而master
分支此刻的提交點並沒有變:
現在,我們把dev
分支的工作成果合並到master
分支上:
1 $ git merge dev 2 Updating d17efd8..fec145a 3 Fast-forward 4 readme.txt | 1 + 5 1 file changed, 1 insertion(+)
git merge
命令用於合並指定分支到當前分支。合並後,再查看readme.txt的內容,就可以看到,和dev
分支的最新提交是完全一樣的。
註意到上面的Fast-forward
信息,Git告訴我們,這次合並是“快進模式”,也就是直接把master
指向dev
的當前提交,所以合並速度非常快。
當然,也不是每次合並都能Fast-forward
,我們後面會講其他方式的合並。
合並完成後,就可以放心地刪除dev
分支了:
1 $ git branch -d dev 2 Deleted branch dev (was fec145a).
刪除後,查看branch
,就只剩下master
分支了:
1 $ git branch 2 * master
因為創建、合並和刪除分支非常快,所以Git鼓勵你使用分支完成某個任務,合並後再刪掉分支,這和直接在master
分支上工作效果是一樣的,但過程更安全。
二、解決沖突
人生不如意之事十之八九,合並分支往往也不是一帆風順的。
準備新的feature1
分支,繼續我們的新分支開發:
1 $ git checkout -b feature1 2 Switched to a new branch ‘feature1‘
修改readme.txt最後一行,改為:
1 Creating a new branch is quick AND simple.
在feature1
分支上提交:
1 $ git add readme.txt 2 $ git commit -m "AND simple" 3 [feature1 75a857c] AND simple 4 1 file changed, 1 insertion(+), 1 deletion(-)
切換到master
分支:
1 $ git checkout master 2 Switched to branch ‘master‘ 3 Your branch is ahead of ‘origin/master‘ by 1 commit.
Git還會自動提示我們當前master
分支比遠程的master
分支要超前1個提交。
在master
分支上把readme.txt文件的最後一行改為:
Creating a new branch is quick & simple.
提交:
1 $ git add readme.txt 2 $ git commit -m "& simple" 3 [master 400b400] & simple 4 1 file changed, 1 insertion(+), 1 deletion(-)
現在,master
分支和feature1
分支各自都分別有新的提交,變成了這樣:
這種情況下,Git無法執行“快速合並”,只能試圖把各自的修改合並起來,但這種合並就可能會有沖突,我們試試看:
1 $ git merge feature1 2 Auto-merging readme.txt 3 CONFLICT (content): Merge conflict in readme.txt 4 Automatic merge failed; fix conflicts and then commit the result.
果然沖突了!Git告訴我們,readme.txt文件存在沖突,必須手動解決沖突後再提交。git status
也可以告訴我們沖突的文件:
1 $ git status 2 # On branch master 3 # Your branch is ahead of ‘origin/master‘ by 2 commits. 4 # 5 # Unmerged paths: 6 # (use "git add/rm <file>..." as appropriate to mark resolution) 7 # 8 # both modified: readme.txt 9 # 10 no changes added to commit (use "git add" and/or "git commit -a")
我們可以直接查看readme.txt的內容:
1 Git is a distributed version control system. 2 Git is free software distributed under the GPL. 3 Git has a mutable index called stage. 4 Git tracks changes of files. 5 <<<<<<< HEAD 6 Creating a new branch is quick & simple. 7 ======= 8 Creating a new branch is quick AND simple. 9 >>>>>>> feature
Git用<<<<<<<
,=======
,>>>>>>>
標記出不同分支的內容,我們修改如下後保存:
Creating a new branch is quick and simple.
再提交:
1 $ git add readme.txt 2 $ git commit -m "conflict fixed" 3 [master 59bc1cb] conflict fixed
現在,master
分支和feature1
分支變成了下圖所示:
用帶參數的git log
也可以看到分支的合並情況:
1 $ git log --graph --pretty=oneline --abbrev-commit 2 * 59bc1cb conflict fixed 3 |4 | * 75a857c AND simple 5 * | 400b400 & simple 6 |/ 7 * fec145a branch test 8 ...
最後,刪除feature1
分支:
1 $ git branch -d feature1 2 Deleted branch feature1 (was 75a857c).
工作完成。
三、分支管理策略
通常,合並分支時,如果可能,Git會用Fast forward
模式,但這種模式下,刪除分支後,會丟掉分支信息。
如果要強制禁用Fast forward
模式,Git就會在merge時生成一個新的commit,這樣,從分支歷史上就可以看出分支信息。
下面我們實戰一下--no-ff
方式的git merge
:
首先,仍然創建並切換dev
分支:
1 $ git checkout -b dev 2 Switched to a new branch ‘dev‘
修改readme.txt文件,並提交一個新的commit:
1 $ git add readme.txt 2 $ git commit -m "add merge" 3 [dev 6224937] add merge 4 1 file changed, 1 insertion(+)
現在,我們切換回master
:
1 $ git checkout master 2 Switched to branch ‘master‘
準備合並dev
分支,請註意--no-ff
參數,表示禁用Fast forward
:
1 $ git merge --no-ff -m "merge with no-ff" dev 2 Merge made by the ‘recursive‘ strategy. 3 readme.txt | 1 + 4 1 file changed, 1 insertion(+)
因為本次合並要創建一個新的commit,所以加上-m
參數,把commit描述寫進去。
合並後,我們用git log
看看分支歷史:
1 $ git log --graph --pretty=oneline --abbrev-commit 2 * 7825a50 merge with no-ff 3 |4 | * 6224937 add merge 5 |/ 6 * 59bc1cb conflict fixed 7 ...
可以看到,不使用Fast forward
模式,merge後就像這樣:
分支策略
在實際開發中,我們應該按照幾個基本原則進行分支管理:
首先,master
分支應該是非常穩定的,也就是僅用來發布新版本,平時不能在上面幹活;
那在哪幹活呢?幹活都在dev
分支上,也就是說,dev
分支是不穩定的,到某個時候,比如1.0版本發布時,再把dev
分支合並到master
上,在master
分支發布1.0版本;
你和你的小夥伴們每個人都在dev
分支上幹活,每個人都有自己的分支,時不時地往dev
分支上合並就可以了。
所以,團隊合作的分支看起來就像這樣:
Git分支十分強大,在團隊開發中應該充分應用。
合並分支時,加上--no-ff
參數就可以用普通模式合並,合並後的歷史有分支,能看出來曾經做過合並,而fast forward
合並就看不出來曾經做過合並。
四、Bug分支
軟件開發中,bug就像家常便飯一樣。有了bug就需要修復,在Git中,由於分支是如此的強大,所以,每個bug都可以通過一個新的臨時分支來修復,修復後,合並分支,然後將臨時分支刪除。
當你接到一個修復一個代號101的bug的任務時,很自然地,你想創建一個分支issue-101
來修復它,但是,等等,當前正在dev
上進行的工作還沒有提交:
1 $ git status 2 # On branch dev 3 # Changes to be committed: 4 # (use "git reset HEAD <file>..." to unstage) 5 # 6 # new file: hello.py 7 # 8 # Changes not staged for commit: 9 # (use "git add <file>..." to update what will be committed) 10 # (use "git checkout -- <file>..." to discard changes in working directory) 11 # 12 # modified: readme.txt 13 #
並不是你不想提交,而是工作只進行到一半,還沒法提交,預計完成還需1天時間。但是,必須在兩個小時內修復該bug,怎麽辦?
幸好,Git還提供了一個stash
功能,可以把當前工作現場“儲藏”起來,等以後恢復現場後繼續工作:
1 $ git stash 2 Saved working directory and index state WIP on dev: 6224937 add merge 3 HEAD is now at 6224937 add merge
現在,用git status
查看工作區,就是幹凈的(除非有沒有被Git管理的文件),因此可以放心地創建分支來修復bug。
首先確定要在哪個分支上修復bug,假定需要在master
分支上修復,就從master
創建臨時分支:
1 $ git checkout master 2 Switched to branch ‘master‘ 3 Your branch is ahead of ‘origin/master‘ by 6 commits. 4 $ git checkout -b issue-101 5 Switched to a new branch ‘issue-101‘
現在修復bug,需要把“Git is free software ...”改為“Git is a free software ...”,然後提交:
1 $ git add readme.txt 2 $ git commit -m "fix bug 101" 3 [issue-101 cc17032] fix bug 101 4 1 file changed, 1 insertion(+), 1 deletion(-)
修復完成後,切換到master
分支,並完成合並,最後刪除issue-101
分支:
1 $ git checkout master 2 Switched to branch ‘master‘ 3 Your branch is ahead of ‘origin/master‘ by 2 commits. 4 $ git merge --no-ff -m "merged bug fix 101" issue-101 5 Merge made by the ‘recursive‘ strategy. 6 readme.txt | 2 +- 7 1 file changed, 1 insertion(+), 1 deletion(-) 8 $ git branch -d issue-101 9 Deleted branch issue-101 (was cc17032).
太棒了,原計劃兩個小時的bug修復只花了5分鐘!現在,是時候接著回到dev
分支幹活了!
1 $ git checkout dev 2 Switched to branch ‘dev‘ 3 $ git status 4 # On branch dev 5 nothing to commit (working directory clean)
工作區是幹凈的,剛才的工作現場存到哪去了?用git stash list
命令看看:
1 $ git stash list 2 stash@{0}: WIP on dev: 6224937 add merge
工作現場還在,Git把stash內容存在某個地方了,但是需要恢復一下,有兩個辦法:
一是用git stash apply
恢復,但是恢復後,stash內容並不刪除,你需要用git stash drop
來刪除;
另一種方式是用git stash pop
,恢復的同時把stash內容也刪了:
1 $ git stash pop 2 # On branch dev 3 # Changes to be committed: 4 # (use "git reset HEAD <file>..." to unstage) 5 # 6 # new file: hello.py 7 # 8 # Changes not staged for commit: 9 # (use "git add <file>..." to update what will be committed) 10 # (use "git checkout -- <file>..." to discard changes in working directory) 11 # 12 # modified: readme.txt 13 # 14 Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)
再用git stash list
查看,就看不到任何stash內容了:
$ git stash list
你可以多次stash,恢復的時候,先用git stash list
查看,然後恢復指定的stash,用命令:
$ git stash apply stash@{0}
修復bug時,我們會通過創建新的bug分支進行修復,然後合並,最後刪除;
當手頭工作沒有完成時,先把工作現場git stash
一下,然後去修復bug,修復後,再git stash pop
,回到工作現場。
五、Feature分支
軟件開發中,總有無窮無盡的新的功能要不斷添加進來。
添加一個新功能時,你肯定不希望因為一些實驗性質的代碼,把主分支搞亂了,所以,每添加一個新功能,最好新建一個feature分支,在上面開發,完成後,合並,最後,刪除該feature分支。
現在,你終於接到了一個新任務:開發代號為Vulcan的新功能,該功能計劃用於下一代星際飛船。
於是準備開發:
1 $ git checkout -b feature-vulcan 2 Switched to a new branch ‘feature-vulcan‘
5分鐘後,開發完畢:
1 $ git add vulcan.py 2 $ git status 3 # On branch feature-vulcan 4 # Changes to be committed: 5 # (use "git reset HEAD <file>..." to unstage) 6 # 7 # new file: vulcan.py 8 # 9 $ git commit -m "add feature vulcan" 10 [feature-vulcan 756d4af] add feature vulcan 11 1 file changed, 2 insertions(+) 12 create mode 100644 vulcan.py
切回dev
,準備合並:
$ git checkout dev
一切順利的話,feature分支和bug分支是類似的,合並,然後刪除。
但是,
就在此時,接到上級命令,因經費不足,新功能必須取消!
雖然白幹了,但是這個分支還是必須就地銷毀:
1 $ git branch -d feature-vulcan 2 error: The branch ‘feature-vulcan‘ is not fully merged. 3 If you are sure you want to delete it, run ‘git branch -D feature-vulcan‘.
銷毀失敗。Git友情提醒,feature-vulcan
分支還沒有被合並,如果刪除,將丟失掉修改,如果要強行刪除,需要使用命令git branch -D feature-vulcan
。
現在我們強行刪除:
1 $ git branch -D feature-vulcan 2 Deleted branch feature-vulcan (was 756d4af).
終於刪除成功!
開發一個新feature,最好新建一個分支;
如果要丟棄一個沒有被合並過的分支,可以通過git branch -D <name>
強行刪除。
六、多人協作
當你從遠程倉庫克隆時,實際上Git自動把本地的master
分支和遠程的master
分支對應起來了,並且,遠程倉庫的默認名稱是origin
。
要查看遠程庫的信息,用git remote
:
1 $ git remote 2 origin
或者,用git remote -v
顯示更詳細的信息:
1 $ git remote -v 2 origin [email protected]:michaelliao/learngit.git (fetch) 3 origin [email protected]:michaelliao/learngit.git (push)
上面顯示了可以抓取和推送的origin
的地址。如果沒有推送權限,就看不到push的地址。
推送分支
推送分支,就是把該分支上的所有本地提交推送到遠程庫。推送時,要指定本地分支,這樣,Git就會把該分支推送到遠程庫對應的遠程分支上:
1 $ git push origin master
如果要推送其他分支,比如dev
,就改成:
1 $ git push origin dev
但是,並不是一定要把本地分支往遠程推送,那麽,哪些分支需要推送,哪些不需要呢?
-
master
分支是主分支,因此要時刻與遠程同步; -
dev
分支是開發分支,團隊所有成員都需要在上面工作,所以也需要與遠程同步; -
bug分支只用於在本地修復bug,就沒必要推到遠程了,除非老板要看看你每周到底修復了幾個bug;
-
feature分支是否推到遠程,取決於你是否和你的小夥伴合作在上面開發。
總之,就是在Git中,分支完全可以在本地自己藏著玩,是否推送,視你的心情而定!
抓取分支
多人協作時,大家都會往master
和dev
分支上推送各自的修改。
現在,模擬一個你的小夥伴,可以在另一臺電腦(註意要把SSH Key添加到GitHub)或者同一臺電腦的另一個目錄下克隆:
1 $ git clone [email protected]:michaelliao/learngit.git 2 Cloning into ‘learngit‘... 3 remote: Counting objects: 46, done. 4 remote: Compressing objects: 100% (26/26), done. 5 remote: Total 46 (delta 16), reused 45 (delta 15) 6 Receiving objects: 100% (46/46), 15.69 KiB | 6 KiB/s, done. 7 Resolving deltas: 100% (16/16), done.
當你的小夥伴從遠程庫clone時,默認情況下,你的小夥伴只能看到本地的master
分支。不信可以用git branch
命令看看:
1 $ git branch 2 * master
現在,你的小夥伴要在dev
分支上開發,就必須創建遠程origin
的dev
分支到本地,於是他用這個命令創建本地dev
分支:
1 $ git checkout -b dev origin/dev
現在,他就可以在dev
上繼續修改,然後,時不時地把dev
分支push
到遠程:
1 $ git commit -m "add /usr/bin/env" 2 [dev 291bea8] add /usr/bin/env 3 1 file changed, 1 insertion(+) 4 $ git push origin dev 5 Counting objects: 5, done. 6 Delta compression using up to 4 threads. 7 Compressing objects: 100% (2/2), done. 8 Writing objects: 100% (3/3), 349 bytes, done. 9 Total 3 (delta 0), reused 0 (delta 0) 10 To [email protected]:michaelliao/learngit.git 11 fc38031..291bea8 dev -> dev
你的小夥伴已經向origin/dev
分支推送了他的提交,而碰巧你也對同樣的文件作了修改,並試圖推送:
1 $ git add hello.py 2 $ git commit -m "add coding: utf-8" 3 [dev bd6ae48] add coding: utf-8 4 1 file changed, 1 insertion(+) 5 $ git push origin dev 6 To [email protected]:michaelliao/learngit.git 7 ! [rejected] dev -> dev (non-fast-forward) 8 error: failed to push some refs to ‘[email protected]:michaelliao/learngit.git‘ 9 hint: Updates were rejected because the tip of your current branch is behind 10 hint: its remote counterpart. Merge the remote changes (e.g. ‘git pull‘) 11 hint: before pushing again. 12 hint: See the ‘Note about fast-forwards‘ in ‘git push --help‘ for details.
推送失敗,因為你的小夥伴的最新提交和你試圖推送的提交有沖突,解決辦法也很簡單,Git已經提示我們,先用git pull
把最新的提交從origin/dev
抓下來,然後,在本地合並,解決沖突,再推送:
1 $ git pull 2 remote: Counting objects: 5, done. 3 remote: Compressing objects: 100% (2/2), done. 4 remote: Total 3 (delta 0), reused 3 (delta 0) 5 Unpacking objects: 100% (3/3), done. 6 From github.com:michaelliao/learngit 7 fc38031..291bea8 dev -> origin/dev 8 There is no tracking information for the current branch. 9 Please specify which branch you want to merge with. 10 See git-pull(1) for details 11 12 git pull <remote> <branch> 13 14 If you wish to set tracking information for this branch you can do so with: 15 16 git branch --set-upstream dev origin/<branch>
git pull
也失敗了,原因是沒有指定本地dev
分支與遠程origin/dev
分支的鏈接,根據提示,設置dev
和origin/dev
的鏈接:
1 $ git branch --set-upstream dev origin/dev 2 Branch dev set up to track remote branch dev from origin.
再pull:
1 $ git pull 2 Auto-merging hello.py 3 CONFLICT (content): Merge conflict in hello.py 4 Automatic merge failed; fix conflicts and then commit the result.
這回git pull
成功,但是合並有沖突,需要手動解決,解決的方法和分支管理中的解決沖突完全一樣。解決後,提交,再push:
1 $ git commit -m "merge & fix hello.py" 2 [dev adca45d] merge & fix hello.py 3 $ git push origin dev 4 Counting objects: 10, done. 5 Delta compression using up to 4 threads. 6 Compressing objects: 100% (5/5), done. 7 Writing objects: 100% (6/6), 747 bytes, done. 8 Total 6 (delta 0), reused 0 (delta 0) 9 To [email protected]:michaelliao/learngit.git 10 291bea8..adca45d dev -> dev
因此,多人協作的工作模式通常是這樣:
-
首先,可以試圖用
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
,如果有沖突,要先處理沖突。
4、git分支管理