1、git分支的理論知識
我們假設現在有一個工作目錄，裏面包含了三個將要被暫存和提交的文件。 暫存操作會爲每一個文件計算校驗和（SHA-1 哈希算法），然後會把當前版本的文件快照保存到 Git 倉庫中（Git 使用 blob 對象來保存它們），最終將校驗和加入到暫存區域等待提交
當使用 git commit 進行提交操作時，Git 會先計算每一個子目錄的校驗和，然後在 Git 倉庫中這些校驗和保存爲樹對象。 隨後，Git 便會創建一個提交對象，該提交對象會包含一個指向快照的指針，還包含了作者的姓名和郵箱、提交時輸入的信息、指向它的父對象的指針以及包含指向這個樹對象的指針。
每次提交，Git 會保存一個提交對象，多次提交之後，那麼這次產生的提交對象會包含一個指向上次提交對象（父對象）的指針。
每次提交，Git都把它們串成一條時間線。
Git 的分支，本質上是指向提交對象的可變指針
Git 是怎麼知道當前在哪一個分支上？
很簡單，它有一個名爲 HEAD 的特殊指針，可以將 HEAD 想象爲當前分支的別名，HEAD指向的就是當前分支。
一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，
就能確定當前分支，以及當前分支的提交點：
每次提交(commit)，master分支都會向前移動一步，隨着你不斷提交，master分支的線也越來越長。
當我們創建新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，通過checkout命令再把HEAD指向dev，就表示當前分支在dev上：
從現在開始，對工作區的修改和提交就是針對dev分支了，提交一次（commit），dev指針往前移動一步，而master指針不變
假如我們在dev上的工作完成了，我們切換到master分支的時候，可以看到工作區文件是之前的樣子，所以切換分支不僅使HEAD指回master 分支，而且將工作目錄恢復成 master 分支所指向的快照內容
現在我們可以把dev合併到master上，合併就是把master指向dev的當前提交，就完成了合併：
合併完分支後，可以刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉後，我們就剩下了一條master分支
2、git分支操作
a、創建分支，要確定在哪個分支上創建子分支
在當前分支下創建dev分支：
$ git checkout -b dev
補充：
1、$ git checkout 直接加文件名，是撤消工作區修改。
2、$ git checkout 直接分支名稱，是切換分支。
b、查看當前分支，當前分支前面會標一個*號
$ git branch
現在在dev分支上正常提交，比如對helloWorldGit.txt做個修改，加上一行，然後提交
c、將dev分支合併到master分支
現在切換到master分支上，查看文件還是master之前的提交狀態，因爲那個提交是在dev分支上，而master分支此刻的提交點並沒有變。
$ git merge dev
git merge命令用於合併指定分支到當前分支。
合併後，再查看文件內容，就可以看到，和dev分支的最新提交是完全一樣的。
注意： Fast-forward信息，Git告訴我們，這次合併是“快進模式”，也就是直接把master指向dev的當前提交，所以合併速度非常快。
當然不是每次合併都能Fast-forward，我們後面會講其他方式的合併。
d、刪除分支
合併完成後，可以刪除dev分支了，指令如下：
$ git branch -d dev
補充：$ git branch是查看所有分支。
3、分支衝突
合併操作不會如此順利， 如果你在兩個不同的分支中，對同一個文件的同一個部分進行了不同的修改，合併它們就會出問題。
現在我們重複上面分支的操作
1 創建一個devOne分支
2 在devOne分支上進行修改和提交操作
3 切換回master分支，對同一個文件進行修改和提交操作
4 合併devOne分支
5 刪除devOne分支
文件內容：
HEAD指向master 分支，在======= 的上半部分，而 devOne分支在 ======= 的下半部分。
你可以選擇使用由 =======分割的兩部分中的一個，也可以自行合併這些內容。
4、解決分支衝突
分析問題出現的原因：既在devOne分支上做了修改提交，也在master分支上對同一文件做了提交，導致合併devOne分支的時候出現了問題。
發生衝突了怎麼辦？
helloWorldGit.txt合併發生了衝突，手動解決後，對每個文件使用 git add 命令來將其標記爲衝突已解決衝突再提交。
helloWorldGit.txt修改後如下：
衝突解決了，最後刪除devOne分支。
5、非Fast forward合併
我們之前說的合併分支時，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。
現在我們不用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。
指令：
$ git merge --no-ff -m “xxx" devTwo
因爲本次合併要創建一個新的commit，所以加上-m參數，把commit描述寫進去，xxx是commit信息。
現在我們進行如下的操作
1、創建一個devTwo分支
2、在devTwo分支上進行修改和提交操作
3、切換回master分支,用非Fast forward的方式合併devTwo分支
4、刪除devTwo分支
查看分支歷史合併情況
$ git log --graph --pretty=oneline --abbrev-commit
不用Fast forward模式，分支歷史上就可以看出分支提交信息和分支的信息
Git也會自動使用非Fast forward模式，如分支分叉的情況，git會自動使用非fast模式
這和之前合併 devTwo分支的時候看起來有一點不一樣，開發歷史從一個更早的地方開始分叉開來。
所以Git 幫我們做了一些額外的工作，出現這種情況的時候，Git 會使用兩個分支的末端所指的快照以及這兩個分支的工作祖先（分叉點），做一個簡單的三方合併。
6、暫存分支
當程序出現bug時，你就需要新建一個臨時分支來修復，修復後，合併分支，然後將臨時分支刪除，但是你當前還在子分支上進行的工作還沒有提交，而且只開發到一半，還不能提交。但是bug需要緊急修復，這個時候怎麼辦？
Git提供了一個stash功能，可以把當前分支暫存起來，之後可以恢復繼續開發。
倉庫版本：
修改後：
文件變會原來的版本
現在我們創建一個子分支來修復bug。
1首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創建分支
2 現在修復bug，插入bug修復，然後提交：
3 修復完成後，切換到master分支併合並bug001分支
4 刪除bug001分支
Bug修復完成了，我們回到devThree分支繼續之前的開發
查看我們的暫存分支
$ git stash list
恢復我們的暫存分支
a：一是用git stash apply xxx恢復，stash內容並不刪除，還需要git stash drop來刪除；
b：另一種方式是用git stash pop，恢復的同時把stash內容也刪了：
7、刪除已經提交（未合併）的分支
$ git branch -D xxxxx
1 我們新建了 一個分支，已經完成了並提交（commit）的開發，但是這個時候不需要此需求了，應該把此分支刪除。
2 提示還沒有合併，無法刪除，Git提示將-d改成-D強制刪除已經提交的分支，但是丟失修改
