為了真正理解 Git 處理分支的方式箱蝠，我們需要回顧一下 Git 是如何保存數(shù)據(jù)的。
或許你還記得 起步 的內(nèi)容垦垂，Git 保存的不是文件的變化或者差異宦搬，而是一系列不同時刻的文件快照。
在進(jìn)行提交操作時劫拗，Git 會保存一個提交對象（commit object）间校。知道了 Git 保存數(shù)據(jù)的方式，我們可以很自然的想到——該提交對象會包含一個指向暫存內(nèi)容快照的指針页慷。 但不僅僅是這樣憔足，該提交對象還包含了作者的姓名和郵箱胁附、提交時輸入的信息以及指向它的父對象的指針。首次提交產(chǎn)生的提交對象沒有父對象滓彰，普通提交操作產(chǎn)生的提交對象有一個父對象控妻，而由多個分支合并產(chǎn)生的提交對象有多個父對象，
為了更加形象地說明揭绑，我們假設(shè)現(xiàn)在有一個工作目錄弓候，里面包含了三個將要被暫存和提交的文件。 暫存操作會為每一個文件計算校驗和（使用我們在 起步 中提到的 SHA-1 哈希算法）他匪，然后會把當(dāng)前版本的文件快照保存到 Git 倉庫中（Git 使用 blob 對象來保存它們）菇存，最終將校驗和加入到暫存區(qū)域等待提交：
$ git add README test.rb LICENSE
$ git commit -m 'The initial commit of my project'
當(dāng)使用 git commit 進(jìn)行提交操作時，Git 會先計算每一個子目錄（本例中只有項目根目錄）的校驗和邦蜜，然后在 Git 倉庫中這些校驗和保存為樹對象依鸥。 隨后，Git 便會創(chuàng)建一個提交對象悼沈，它除了包含上面提到的那些信息外毕籽，還包含指向這個樹對象（項目根目錄）的指針。如此一來井辆，Git 就可以在需要的時候重現(xiàn)此次保存的快照关筒。
現(xiàn)在，Git 倉庫中有五個對象：三個 blob 對象（保存著文件快照）杯缺、一個樹對象（記錄著目錄結(jié)構(gòu)和 blob 對象索引）以及一個提交對象（包含著指向前述樹對象的指針和所有提交信息）蒸播。
Figure 9. 首次提交對象及其樹結(jié)構(gòu)
做些修改后再次提交，那么這次產(chǎn)生的提交對象會包含一個指向上次提交對象（父對象）的指針萍肆。
Figure 10. 提交對象及其父對象
Git 的分支袍榆，其實本質(zhì)上僅僅是指向提交對象的可變指針。 Git 的默認(rèn)分支名字是 master塘揣。 在多次提交操作之后包雀，你其實已經(jīng)有一個指向最后那個提交對象的 master 分支。 它會在每次的提交操作中自動向前移動亲铡。
Git 的 “master” 分支并不是一個特殊分支才写。 它就跟其它分支完全沒有區(qū)別。 之所以幾乎每一個倉庫都有 master 分支奖蔓，是因為 git init 命令默認(rèn)創(chuàng)建它赞草，并且大多數(shù)人都懶得去改動它。
Figure 11. 分支及其提交歷史
分支創(chuàng)建
Git 是怎么創(chuàng)建新分支的呢吆鹤？ 很簡單厨疙，它只是為你創(chuàng)建了一個可以移動的新的指針。 比如疑务，創(chuàng)建一個 testing 分支沾凄， 你需要使用 git branch 命令：
$ git branch testing
這會在當(dāng)前所在的提交對象上創(chuàng)建一個指針梗醇。
兩個指向相同提交歷史的分支。
Figure 12. 兩個指向相同提交歷史的分支
那么撒蟀，Git 又是怎么知道當(dāng)前在哪一個分支上呢婴削？ 也很簡單，它有一個名為 HEAD 的特殊指針牙肝。 請注意它和許多其它版本控制系統(tǒng)（如 Subversion 或 CVS）里的 HEAD 概念完全不同。 在 Git 中嗤朴，它是一個指針配椭，指向當(dāng)前所在的本地分支（譯注：將 HEAD 想象為當(dāng)前分支的別名）。 在本例中雹姊，你仍然在 master 分支上股缸。 因為 git branch 命令僅僅 創(chuàng)建 一個新分支，并不會自動切換到新分支中去吱雏。
HEAD 指向當(dāng)前所在的分支敦姻。
Figure 13. HEAD 指向當(dāng)前所在的分支
你可以簡單地使用 git log 命令查看各個分支當(dāng)前所指的對象。 提供這一功能的參數(shù)是 --decorate歧杏。
$ git log --oneline --decorate
f30ab (HEAD, master, testing) add feature #32 - ability to add new
34ac2 fixed bug #1328 - stack overflow under certain conditions
98ca9 initial commit of my project
正如你所見镰惦，當(dāng)前 “master” 和 “testing” 分支均指向校驗和以 f30ab 開頭的提交對象。
分支切換
要切換到一個已存在的分支犬绒，你需要使用 git checkout 命令旺入。 我們現(xiàn)在切換到新創(chuàng)建的 testing 分支去：
$ git checkout testing
這樣 HEAD 就指向 testing 分支了。
HEAD 指向當(dāng)前所在的分支凯力。
Figure 14. HEAD 指向當(dāng)前所在的分支
那么茵瘾，這樣的實現(xiàn)方式會給我們帶來什么好處呢？ 現(xiàn)在不妨再提交一次：
$ vim test.rb
$ git commit -a -m 'made a change'
HEAD 分支隨著提交操作自動向前移動咐鹤。
Figure 15. HEAD 分支隨著提交操作自動向前移動
如圖所示拗秘，你的 testing 分支向前移動了，但是 master 分支卻沒有祈惶，它仍然指向運行 git checkout 時所指的對象雕旨。 這就有意思了，現(xiàn)在我們切換回 master 分支看看：
$ git checkout master
檢出時 HEAD 隨之移動捧请。
Figure 16. 檢出時 HEAD 隨之移動
這條命令做了兩件事奸腺。 一是使 HEAD 指回 master 分支，二是將工作目錄恢復(fù)成 master 分支所指向的快照內(nèi)容血久。 也就是說突照，你現(xiàn)在做修改的話，項目將始于一個較舊的版本氧吐。 本質(zhì)上來講讹蘑，這就是忽略 testing 分支所做的修改末盔，以便于向另一個方向進(jìn)行開發(fā)。
分支切換會改變你工作目錄中的文件
在切換分支時座慰，一定要注意你工作目錄里的文件會被改變陨舱。 如果是切換到一個較舊的分支，你的工作目錄會恢復(fù)到該分支最后一次提交時的樣子版仔。 如果 Git 不能干凈利落地完成這個任務(wù)游盲，它將禁止切換分支。
我們不妨再稍微做些修改并提交：
$ vim test.rb
$ git commit -a -m 'made other changes'
現(xiàn)在蛮粮，這個項目的提交歷史已經(jīng)產(chǎn)生了分叉（參見 項目分叉歷史）益缎。 因為剛才你創(chuàng)建了一個新分支，并切換過去進(jìn)行了一些工作然想，隨后又切換回 master 分支進(jìn)行了另外一些工作莺奔。 上述兩次改動針對的是不同分支：你可以在不同分支間不斷地來回切換和工作，并在時機成熟時將它們合并起來变泄。 而所有這些工作令哟，你需要的命令只有 branch、checkout 和 commit妨蛹。
Figure 17. 項目分叉歷史
你可以簡單地使用 git log 命令查看分叉歷史屏富。 運行 git log --oneline --decorate --graph --all ，它會輸出你的提交歷史蛙卤、各個分支的指向以及項目的分支分叉情況役听。
$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project
由于 Git 的分支實質(zhì)上僅是包含所指對象校驗和（長度為 40 的 SHA-1 值字符串）的文件，所以它的創(chuàng)建和銷毀都異常高效表窘。 創(chuàng)建一個新分支就相當(dāng)于往一個文件中寫入 41 個字節(jié)（40 個字符和 1 個換行符）典予，如此的簡單能不快嗎？
這與過去大多數(shù)版本控制系統(tǒng)形成了鮮明的對比乐严，它們在創(chuàng)建分支時瘤袖，將所有的項目文件都復(fù)制一遍，并保存到一個特定的目錄昂验。 完成這樣繁瑣的過程通常需要好幾秒鐘捂敌，有時甚至需要好幾分鐘。所需時間的長短既琴，完全取決于項目的規(guī)模占婉。而在 Git 中，任何規(guī)模的項目都能在瞬間創(chuàng)建新分支甫恩。 同時逆济，由于每次提交都會記錄父對象，所以尋找恰當(dāng)?shù)暮喜⒒A(chǔ)（譯注：即共同祖先）也是同樣的簡單和高效。 這些高效的特性使得 Git 鼓勵開發(fā)人員頻繁地創(chuàng)建和使用分支奖慌。
