轉：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

所以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裏，這個分支叫主分支，即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創建分支

1. 在本地使用分支。本來在master分支上開發的,如果我沒實現一個小的功能,就進行一次commit的話?那麽分支上不就有很多的commit的嗎?推送上去,您會看見服務器上有很多不必要的提交,這樣子就不簡潔了,版本歷史也不清楚.但是使用分支,完成一個完整的功能,然後主分支使用 git merge --squash branchName 合並分支,做一個整的提交推送,那麽服務器上的歷史只有這一個commit的了,這不就簡潔了嗎?

2. 在服務端,我有多個小組,每個小組是一個分支,因為master是保持最穩定代碼的版本,所以我要審查過每個分支上的代碼再合並,而不是立刻將他們分支上的合並到master上面,一來保證了代碼的質量,而來在小組方面可以更快發現bug,然後通知修改。比如穩定的版本放在master 供大家用 在開發的版本放在test 等test完成後 合並到master test上繼續下一步的版本開發

git 分支branch