本節主要知識點：
創建分支
使用
git branch 分支名命令：：
顯示指向這個提交的所有引用（比如 分支以及後面會講的標籤）
執行
git log --decorate命令
切換分支
執行
git checkout 分支名命令
以圖的形式顯示指向這個提交的所有引用
執行
git log --decorate --oneline --graph --all命令：
–graph 選項表示讓 Git 繪製分支圖，–all 表示顯示所有分支
補充:Git 在實際開發中是如何進行分支管理的
分支是什麼？
假設你的大項目已經上線了（有上百萬人在使用呢），過了一段時間你突然覺得應該添加一些新的功能，但是爲了保險起見，你肯定不能在當前項目上直接進行開發，這時候你就有（創）（建）（分）（支）的需要了。
放個大圖先讓你知道分支大概是咋回事：
如果沒有分支，整個產品的迭代週期就會因爲新功能的開發而被延誤（因爲還有補 bug 這樣比較着急的任務）
記得在第一講介紹 Git 的時候跟大家分享過資深玩家對 SVN 的吐槽：
克隆一份全新的目錄以同樣擁有 5 個分支來說，SVN 是同時復製 5 個版本的文件，也就是說重複 5 次同樣的動作。而 Git 只是獲取文件的每個版本的元素，然後只載入主要的分支（master）在我的經驗，克隆一個擁有將近一萬個提交（commit），5 個分支，每個分支有大約 1500 個文件的 SVN，耗了將近 1 小時！而 Git 只用了區區的 1 分鐘！
“克隆一個擁有將近一萬個提交（commit），5 個分支，每個分支有大約 1500 個文件的 SVN，耗了將近 1 小時！而 Git 只用了區區的 1 分鐘！”
我們深入一點思考，到底是什麼成就了 Git ？
Git實用教程:Git 理論基礎 中，我們介紹理論的時候，說 Git 採用一種看似“異端”的形式來處理版本迭代 —— 通常的版本控制系統是採用增量文件系統（增量文件系統的意思就是說新的快照存放的是與舊的快照不同的那一部分內容）來管理版本迭代；而 Git 則是採用將每個版本都獨立存儲的方式 —— 看上去使用 Git 會耗費更多的空間，但來到分支管理這一塊，卻成了 Git 完勝其它版本控制系統的關鍵！
因爲對於其它版本控制系統而言，創建分支常常需要完全創建一個源代碼目錄的副本，項目越大，耗費的時間就越多；而 Git 由於每一個結點都已經是一個完整的項目，所以只需要創建多一個“指針”（像 master）指向分支開始的位置即可。
創建分支
下邊我給大家演示如何創建和切換分支，我們來到之前的 MyProject2（如果你已經刪了，沒關係，重新創建一個項目，然後隨便寫點東西，提交然後修改，再提交，即可）：
MyProject2 現在倉庫裏的情況如下：
好，現在我們開始創建分支！
創建分支，使用 git branch 分支名 命令：
沒有任何提示說明分支創建成功（一般也不會失敗啦，除非創建了同名的分支會提醒你一下），
此時可以執行 git log --decorate 命令查看：
decorate 這個選項是讓 log 顯示指向這個提交的所有引用（比如 分支以及後面會講的標籤）
大家會看到 原來的 （HEAD -> master）變成了 （HEAD -> master，feature）
它的意思是：目前有兩個分支，一個是主分支（master），一個是剛纔我們創建的新分支（feature），然後 HEAD 指針仍然指向默認的 master 分支。
所以目前倉庫中的快照應該是這樣：
創建分支我們會了，接下來就是切換分支。
切換分支
現在我們需要將工作環境從默認的 master 分支切換到新創建的分支（feature）上，使用的就是之前我們欲言又止的 checkout 命令。
git checkout 分支名
執行 git checkout feature 命令：
這樣 HEAD 指針就指向 feature 分支了：
證據在這裏：
（如果希望以“精簡版”的方式顯示，可以加上一個 --oneline 選項（即 git log --decorate --oneline），這樣就只用一行來顯示一個快照記錄。）
看到沒有？HEAD 指針已經指向了 feature 分支：（HEAD -> feature）
我們現在對 MyProject2 裏面的文件進行修改，我們就改一下 DEADME.md 爲例。
執行 git status 命令查看狀態：
然後 提交到暫存區域。
可以看到 README.md 文件被修改並添加到暫存區域（還沒有提交），所以當前三棵樹應該是這樣：
現在我們進行一次提交：（其實只要是在切換分支之後使用 commit 提交的都會歸爲切換後的分支上去，即使是在創建和切換分支使用了 add 添加到了暫存區域，即在那個分支提交的就屬於哪個分支）
現在倉庫中的快照應該是這樣：
然後我們將 HEAD 指針切回 master 分支：
你們現在可以看一下 README.md 文件，細心的朋友會發現上一次對 README.md 文件的修改已經蕩然無存了，這是因爲我們的工作目錄已經回到 master 分支的狀態中：
並且此時我們 使用 git log 命令查看歷史記錄，是看不到 feature 分支的，因爲從 HEAD 出發沒有線指向 feature
現在對 README.md 文件進行修改（隨便改改），然後執行git add 文件名 和 git commit -m "change the README file again"：
好了，目前倉庫中的快照應該變成了醬紫：
讓 Git 自己來告訴你！
執行 git log --decorate --oneline --graph --all 命令：
--graph 選項表示讓 Git 繪製分支圖，--all 表示顯示所有分支
補充
下面給大家介紹一下 Git 在實際開發中是如何進行分支管理的
Git 工作流程
Git 工作流使用一箇中間倉庫作爲所有開發者的交流地點，開發程序的小夥伴在本地工作，然後將各自的分支推送到中間倉庫。
開發分支（develop）
![]()
代替單一的 master 主分支，上圖的工作流使用了兩個分支來處理項目發佈和日常開發。
master 主分支通常只是用於對外發布項目的新版本，日常開發應該在另一條分支上完成。我們把開發用的分支叫做 develop 分支。
功能分支（feature）
每一個新功能應該使用單獨一個功能分支進行開發，功能分支應該從開發分支中分離出來，功能開發完成後合併到開發分支。
提示1：功能分支不應該跟 master 分支有任何交流。
提示2：功能分支可以採用 feature-* 的形式命名。
預發佈分支（release）
在項目正式發佈之前，你可能需要一個預發佈的版本進行測試。於是你可以從開發分支中分離出預發佈分支，用於內部或公開的測試。
提示1：預發佈分支應該同時合併到主分支和開發分支中。
提示2：預發佈分支可以採用 release-* 的形式命名。
維護分支（hotfix）
項目正式發佈後難免會出現 bug，這時就需要創建一個分支，進行 bug 的修補。
提示1：維護分支應該從主分支中分離出來，bug 被修補後，再合併到主分支和開發分支中。
提示2：維護分支可以採用 fixbug-* 的形式命名。
常設分支
常設分支就主分支（master）和開發分支（develop）兩個即可，另外的功能分支（feature）、預發佈分支（release）和維護分支（hotfix）屬於臨時分支，用完之後應該及時刪除。
So，在正式開發中，Git 的分支管理如下：