http://blog.csdn.net/pipisorry/article/details/46958699
分支的意義
創建分支能夠避免提交代碼後對主分支的影響，同一時候也使你有了相對獨立的開發環境。

假設你準備開發一個新功能。可是須要兩周才幹完畢，第一周你寫了50%的代碼，假設立馬提交，由於代碼還沒寫完，不完整的代碼庫會導致別人不能幹活了。

假設等代碼所有寫完再一次提交。又存在丟失每天進度的巨大風險。如今有了分支，就不用怕了。你創建了一個屬於你自己的分支。別人看不到，還繼續在原來的分支上正常工作。而你在自己的分支上幹活，想提交就提交，直到開發完畢後。再一次性合並到原來的分支上，這樣。既安全。又不影響別人工作。

分支管理使用基本命令

創建並切換到新分支

git checkout -b new_branch

新建分支

git branch new_branch

查看當前分支

git branch
切換到master分支

(dev): git checkout master

Note: 切換分支後你會發現本地文件會變化，假設dev分支和master文件不同的話。再cheout回來就又能夠看到之前分支的文件了。只是git2.0以上好像都看得到文件。

在dev分支中時，能夠通過git pull origin master將master分支上的文件下載到本地當前分支中。
合並分支到當前分支

git merge命令用於合並指定分支到當前分支
把dev分支的工作成果合並到master分支上：

$(master): git merge dev

合並分支的操作是從new_branch合並到master分支(這時master的內容就變成了dev的內容)，當前環境在master分支。

刪除分支

git branch -d new_branch

皮皮Blog

git分支使用

每次提交，Git都把它們串成一條時間線。這條時間線就是一個分支。截止到眼下，僅僅有一條時間線，在Git裏。這個分支叫主分支，即master分支。

HEAD嚴格來說不是指向提交。而是指向master。master才是指向提交的，所以。HEAD指向的就是當前分支。

一開始的時候，master分支是一條線，Git用master指向最新的提交。再用HEAD

每次提交。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分支：

git分支管理實戰

首先，我們創建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 fec145a] branch test
 1 file changed, 1 insertion(+)

如今。dev分支的工作完畢。我們就能夠切換回master分支：

$ git checkout master
Switched to branch ‘master‘

切換回master分支後，再查看一個readme.txt文件，剛才加入的內容不見了！由於那個提交是在dev分支上，而master分支此刻的提交點並沒有變：

如今。我們把dev分支的工作成果合並到master分支上：（這通常是從dev分支上提交一個版本號如1.0到master主分支上，這樣master分支和dev分支的內容一樣了）

$ git merge dev
Updating d17efd8..fec145a
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 fec145a).

刪除後。查看branch。就僅僅剩下master分支了：

$ git branch
* master

由於創建、合並和刪除分支很快，所以Git鼓舞你使用分支完畢某個任務，合並後再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。

[創建與合並分支]

皮皮Blog

分支管理策略

通常。合並分支時，假設可能，Git會用Fast forward模式，但這樣的模式下。刪除分支後，會丟掉分支信息。

假設要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就能夠看出分支信息。

以下我們實戰一下--no-ff方式的git merge：

首先，仍然創建並切換dev分支：

$ git checkout -b dev
Switched to a new branch ‘dev‘

改動readme.txt文件，並提交一個新的commit：

$ git add readme.txt 
$ git commit -m "add merge"
[dev 6224937] add merge
 1 file changed, 1 insertion(+)

如今，我們切換回master：

$ git checkout master
Switched to branch ‘master‘

準備合並dev分支。請註意--no-ff參數。表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the ‘recursive‘ strategy.
 readme.txt |    1 +
 1 file changed, 1 insertion(+)

由於本次合並要創建一個新的commit。所以加上-m參數，把commit描寫敘述寫進去。

合並後。我們用git log看看分支歷史：

$ git log --graph --pretty=oneline --abbrev-commit
*   7825a50 merge with no-ff
|| * 6224937 add merge
|/
*   59bc1cb conflict fixed
...

能夠看到。不使用Fast forward模式，merge後就像這樣：

實際開發中分支管理的幾個基本原則

首先。master分支應該是很穩定的。也就是僅用來公布新版本號。平時不能在上面幹活。

那在哪幹活呢？幹活都在dev分支上。也就是說。dev分支是不穩定的。到某個時候，比方1.0版本號公布時，再把dev分支合並到master上。在master分支公布1.0版本號；

你和你的小夥伴們每一個人都在dev分支上幹活。每一個人都有自己的分支，時不時地往dev分支上合並就能夠了。

所以，團隊合作的分支看起來就像這樣：

[分支管理策略]

寫保護分支

Github推出了“能夠寫保護的分支”，對多人協作的項目很實用：不得刪除、不得強行推送、僅僅有測試所有通過才接受PR

[About protected branches]

from:http://blog.csdn.net/pipisorry/article/details/46958699

ref:learnGitBranching-demo

Git版本號控制：Git分支處理