爲什麼需要分支
問題情景：開發人員在開發一個新功能，需要兩天完成，第一天完成 50%，如果當天提交，由於代碼還沒寫完，不完整的代碼庫會導致別人不能幹活了。如果等代碼全部寫完再一次提交，又存在丟失第一天進度的巨大風險。
解決方案：創建了一個屬於你自己的分支，別人看不到，別人可以繼續在原來的分支上正常工作，而你在自己的分支上幹活，想提交就提交，直到開發完畢後，再一次性合併到原來的分支上。
Git 分支的生命週期
我們知道，每次提交，
Git都把它們（提交）串成一條時間線，這條時間線就是一個分支。最開始只有一條時間線，在Git裏，這個分支叫主分支，即master分支。HEAD嚴格來說不是指向提交，而是指向master，master纔是指向提交的，所以，HEAD指向的就是當前分支。
初始化後
一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，從而Git通過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 分支的合併
情景1
在master分支上，創建並切換到新的分支dev，在dev分支做了修改並提交後，又切換回到master分支，如何在master分支上合併dev分支？
解決方案：直接使用git merge dev命令將dev分支合併到master分支（當前分支）上，此時採用的是一種Fast-forward（快進模式）的合併方式，也就是直接將master指向 dev的當前提交。
情景2
Git用Fast forward模式合併分支後，如果刪除分支，會丟掉分支信息，如何保留分支信息？
解決方案：強制禁用Fast forward模式（參數--no-ff），此時Git就會在合併時生成一個新的提交，這樣，從分支歷史上就可以看出分支信息。強制禁用Fast forward模式的命令git merge --no-ff -m "merge with no-ff" dev。
情景3
在master分支創建並切換到新的分支dev，在dev分支做了修改並提交，然後切換回到master分支，在master分支上也做了修改並提交（且修改的內容與在 dev分支修改的內容發生衝突），如何合併分支？
解決方案：如果直接使用git merge dev命令，Git將報告文件存在衝突，此時必須手動解決衝突後再提交。
情景4
當前正在 dev分支上工作，但工作還未完成，無法提交，但同時需要修復另外一個新的 bug，怎麼辦？
解決方案：將當前dev分支（有修改當沒有提交）的工作現場儲藏起來，等以後恢復現場後再繼續工作
分支策略
master分支：master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活dev分支：幹活都在dev分支上，比如1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本bug分支：bug分支常用於修復某一個 Bug，feature分支：feature分支常用於開發某一個新功能
參考：廖雪峯的 Git 教程