git 分支branch
轉:https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840038939c291467cc7c747b1810aab2fb8863508000
每次提交,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
分支:
$ git checkout -b dev
Switched to a new branch ‘dev‘
git checkout
命令加上-b
參數表示創建並切換,相當於以下兩條命令:
$ git branch dev
$ git checkout dev
Switched to branch ‘dev‘
然後,用git branch
$ git branch
* dev
master
git branch
命令會列出所有分支,當前分支前面會標一個*
號。
然後,我們就可以在dev
分支上正常提交,比如對readme.txt做個修改,加上一行:
Creating a new branch is quick.
然後提交:
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+)
現在,dev
分支的工作完成,我們就可以切換回master
分支:
$ git checkout master
Switched to branch ‘master‘
切換回master
分支後,再查看一個readme.txt文件,剛才添加的內容不見了!因為那個提交是在dev
分支上,而master
分支此刻的提交點並沒有變:
現在,我們把dev
分支的工作成果合並到master
分支上:
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge
命令用於合並指定分支到當前分支。合並後,再查看readme.txt的內容,就可以看到,和dev
分支的最新提交是完全一樣的。
註意到上面的Fast-forward
信息,Git告訴我們,這次合並是“快進模式”,也就是直接把master
指向dev
的當前提交,所以合並速度非常快。
當然,也不是每次合並都能Fast-forward
,我們後面會講其他方式的合並。
合並完成後,就可以放心地刪除dev
分支了:
$ git branch -d dev
Deleted branch dev (was b17d20e).
刪除後,查看branch
,就只剩下master
分支了:
$ git branch
* master
因為創建、合並和刪除分支非常快,所以Git鼓勵你使用分支完成某個任務,合並後再刪掉分支,這和直接在master
分支上工作效果是一樣的,但過程更安全。
創建與合並分支
Reads: 999298 Edit在版本回退裏,你已經知道,每次提交,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
分支:
$ git checkout -b dev
Switched to a new branch ‘dev‘
git checkout
命令加上-b
參數表示創建並切換,相當於以下兩條命令:
$ git branch dev
$ git checkout dev
Switched to branch ‘dev‘
然後,用git branch
命令查看當前分支:
$ git branch
* dev
master
git branch
命令會列出所有分支,當前分支前面會標一個*
號。
然後,我們就可以在dev
分支上正常提交,比如對readme.txt做個修改,加上一行:
Creating a new branch is quick.
然後提交:
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+)
現在,dev
分支的工作完成,我們就可以切換回master
分支:
$ git checkout master
Switched to branch ‘master‘
切換回master
分支後,再查看一個readme.txt文件,剛才添加的內容不見了!因為那個提交是在dev
分支上,而master
分支此刻的提交點並沒有變:
現在,我們把dev
分支的工作成果合並到master
分支上:
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge
命令用於合並指定分支到當前分支。合並後,再查看readme.txt的內容,就可以看到,和dev
分支的最新提交是完全一樣的。
註意到上面的Fast-forward
信息,Git告訴我們,這次合並是“快進模式”,也就是直接把master
指向dev
的當前提交,所以合並速度非常快。
當然,也不是每次合並都能Fast-forward
,我們後面會講其他方式的合並。
合並完成後,就可以放心地刪除dev
分支了:
$ git branch -d dev
Deleted branch dev (was b17d20e).
刪除後,查看branch
,就只剩下master
分支了:
$ git branch
* master
因為創建、合並和刪除分支非常快,所以Git鼓勵你使用分支完成某個任務,合並後再刪掉分支,這和直接在master
分支上工作效果是一樣的,但過程更安全。
小結
Git鼓勵大量使用分支:
查看分支:git branch
創建分支:git branch <name>
切換分支:git checkout <name>
創建+切換分支:git checkout -b <name>
合並某分支到當前分支:git merge <name>
刪除分支:git branch -d <name>
什麽情況下需要用到git創建分支
- 在本地使用分支。本來在master分支上開發的,如果我沒實現一個小的功能,就進行一次commit的話?那麽分支上不就有很多的commit的嗎?推送上去,您會看見服務器上有很多不必要的提交,這樣子就不簡潔了,版本歷史也不清楚.但是使用分支,完成一個完整的功能,然後主分支使用 git merge --squash branchName 合並分支,做一個整的提交推送,那麽服務器上的歷史只有這一個commit的了,這不就簡潔了嗎?
-
在服務端,我有多個小組,每個小組是一個分支,因為master是保持最穩定代碼的版本,所以我要審查過每個分支上的代碼再合並,而不是立刻將他們分支上的合並到master上面,一來保證了代碼的質量,而來在小組方面可以更快發現bug,然後通知修改。比如穩定的版本放在master 供大家用 在開發的版本放在test 等test完成後 合並到master test上繼續下一步的版本開發
git 分支branch