分支
我們在前面的博客中提到過分支這個概念，比如說master分支，分支在Git中是非常重要的，假設你準備開發一個新功能,但是需要兩週才能完成,第一週你寫了50%的代碼,如果立刻提交,由於代碼還沒寫完,不完整的代碼庫會導致別人不能幹活了。如果等代碼全部寫完再一次提交,又存在丟失每天進度的巨大風險。現在有了分支,就不用怕了。你創建了一個屬於你自己的分支,別人看不到,還繼續在原來的分支上正常工作,而你在自己的分支上幹活,想提交就提交,直到開發完畢後,再一次性合併到原來的分支上,這樣,既安全,又不影響別人工作。
創建與合併分支
在之前的版本回退中，我們知道了Git將每次提交連接成一條時間線，這條時間線就是分支，在剛開始只有一條分支，就是我們的master分支，並且HEAD指針指向master分支，即當前分支，其時HEAD並不是指向提交的，它是指向master，而master指向分支上的每次提交，一開始，master是一條分支線，master指向最新的一次提交，然後HEAD指向master，這樣就可以確定當前分支，以及當前分支的提交點，每次提交，master都會向前移動一步，隨着不斷的提交，master的分支線不斷加長，但我們創建一個新的分支時，比如創建一個dev分支，Git就會生成一個dev指針，並且指向與master相同的一個提交點，當我們切換到dev分支時，HEAD指針就會指向dev，這是當前分支就成爲了dev，因此，在Git中，分支切換的速度是非常快的，因爲只需要將HEAD指針指向所要切換的分支即可，分支切換後，接下來對當前工作區的修改的添加與提交就會都是針對新分支的了，每次提交，dev指針向前移動一步，而master指針不變。
如果我們在dev分支上的工作做完了，那麼我們就可以將分支切換到master分支，然後將dev分支合併到master分支，怎麼合併呢，Git的話就非常的簡單了，直接將master指向dev的當前提交就可以了，這樣就完成了合併
這樣就可以看出來，Git分支的合併也是很快速的，就只是改改指針的位置，工作內容也不改變。合併完成後如果不再使用dev分支。我們可以將它刪除，這樣就又會只有master一條分支了
實戰一下
1、創建並切換分支
git checkout -b dev #這條命令直接創建並且切換dev分支，相當於下面兩條命令：
git branch dev # 創建分支
git checkout dev # 切換分支
2、查看當前分支
git branch
其表示共有兩條分支，當前分支爲dev，HEAD指針指向dev，現在我們就可以在dev分支上正常提交，比如現在對README.txt文件做一個修改，隨便添加一行：
“Create a branch dev is quick”
然後添加修改並提交
接下來我們切換到master分支，查看README.txt內容：
看見沒，master分支工作區的內容並沒有改變，現在的分支狀態是這樣的：
3、下來，我們將dev分支合併到master分支，首先先將分支切換到master ，然後使用命令 git merge dev 將dev分子合併到master
注意上面輸出中的“Fast-forward”信息，Git告訴我們這次合併是“快進模式”，也就是直接把master指向dev的提交，所以速度非常快，也有其他方式的合併，後面再說，合併完成後，不用dev的話，就可以將其放心的刪除了：
git branch -d dev
解決衝突
分支的合併往往不都是一帆風順的，其中總會出現一些問題，下面我們創建一個新的分支feature1來繼續我們的工作：
1、創建並切換feature1分支
2、修改README.txt文件，修改最後一行爲：
“Create a branch feature1 is quick and simple.”
修改完成後添加修改並提交
3、切換到master分支，並修改README.txt文件最後一行爲：
“Create a branch feature1 is quick & simple.”
修改完成後添加修改並提交
現在分支的狀態應該就變成這個樣子了：
master與feature1分支都有自己的最新提交。
4、嘗試在master分支上合併feature1分支，我們想一下，這種情況下指針該怎樣移動，應該會出現衝突吧，先來看看結果：
果不其然，Git告訴我們，README.txt文件存在衝突，必須手動解決之後再提交，使用git status也可以告訴我們是哪個文件衝突了，他說手動解決，那麼該怎樣手動解決呢，我們看看這個衝突的文件內容：
文件中，爲我們指出了當前分支下該文件的內容與feature1分之下該文件的內容，現在讓我們手動解決的話，就是讓我們自己統一一下文件內容，我們將其修改爲下面這樣：
然後再次進行提交：
現在分支的狀態應該是這樣的：
使用git log也可以查看當前分支狀態：
多人協作
當你在本地從遠程倉庫克隆時，Git就自動將本地master分支與遠程master分支對應了起來，並且，遠程庫的名稱是origin，可以使用git remote查看遠程庫名稱，加上-v選項的話，會顯示詳細信息
上面顯示了可以抓取和推送的 origin 的地址。如果沒有推送權限,就看不到push的地址。
推送分支
推送分支就是將該分支上的所有提交推送到遠程庫，推送時，要指定本地分支，這樣Git就會把該分支推送到與遠程庫對應的遠程分支上：
git push origin master
如果要推送其他分支，比如dev，就改成：
git push origin dev
也並不是所有的分支都要向遠程推送，那麼哪些需要，哪些不需要呢？
1、master分支是主分支，要時刻與遠程保持一致；
2、dev分支是團隊協作開發的分支，也要與遠程保持一致；
3、bug分支只用於修復本地bug，沒必要推送到遠程；
4、feature分支如果沒有團隊在上面協作開發的話，就不需要推送到遠程。
抓取分支
在多人協作時，團隊人員都會將自己的修改提交推送到master和dev分支上，現在，我們開啓另外一臺虛擬機並安裝Git，來模擬一下團隊協作，將新開啓的虛擬機的ssh-key添加到github，現在使用新開啓的虛擬機來從遠程庫克隆
默認情況下，新的虛擬機只能看到master分支，可以用git branch查看
現在，你的同事要在dev分支上開發，所以就要創建遠程origin的dev分支到本地，使用下面的命令創建：
git checkout -b dev origin/dev
現在它就可以在dev分支上修改，並不時的將dev分支push到遠程
你的同事已經向origin/dev分支推送了他的提交，恰好，你現在也對同樣的文件做了修改，並且嘗試向遠程推送
推送失敗，這是因爲你同事的最新推送的提交與你嘗試推送的提交有衝突，解決辦法也很簡單，Git提示我們，需要將遠程最新的提交使用git pull抓取下來，然後在本地合併，解決衝突再推送：
git pull也失敗了，原因是沒有設置本地dev分支與遠程origin/dev分支的連接，根據提示設置：
然後再進行pull
拉取下來後進行手動合併，解決衝突後進行推送，解決衝突的方式跟之前分支管理中解決衝突的方法一樣，解決完後就可以推送了
