分支學習
https://gitee.com/progit/3-Git-%E5%88%86%E6%94%AF.html+自己的理解
理解分支的概念並熟練運用後,你纔會意識到爲什麼 Git 是一個如此強大而獨特的工具,並從此真正改變你的開發方式。
就像河流分支一樣,可以分支,可以匯聚。我們的版本庫裏面的項目就是主流,每人都可以取分支去工作,完成後進行合併,這大概就是我理解的分支。
Git 的分支可謂是難以置信的輕量級,它的新建操作幾乎可以在瞬間完成,並且在不同分支間切換起來也差不多一樣快。和許多其他版本控制系統不同,Git 鼓勵在工作流程中頻繁使用分支與合併,哪怕一天之內進行許多次都沒有關係。
理解分支的工作原理:Git 保存的不是文件差異或者變化量,而只是一系列文件快照。
在 Git 中提交時,會保存一個提交(commit)對象,該對象包含一個指向暫存內容快照的指針,包含本次提交的作者等相關附屬信息,包含零個或多個指向該提交對象的父對象指針:首次提交是沒有直接祖先的,普通提交有一個祖先,由兩個或多個分支合併產生的提交則有多個祖先,這裏的祖先指的就是其parent對象。
假設在工作目錄中有三個文件,準備將它們暫存後提交。
暫存操作會對每一個文件計算校驗和(即第一章中提到的 SHA-1 哈希字串),然後把當前版本的文件快照保存到 Git 倉庫中(Git 使用 blob 類型的對象存儲這些快照),並將校驗和加入暫存區域:
ps:BLOB (binary large object),二進制大對象,是一個可以存儲二進制文件的容器。在計算機中,BLOB常常是數據庫中用 來存儲二進制文件的字段類型。
$ git add README test.rb LICENSE
$ git commit -m 'initial commit of my project'
當使用 git commit
新建一個提交對象前,Git 會先計算每一個子目錄(本例中就是項目根目錄)的校驗和,然後在 Git 倉庫中將這些目錄保存爲樹(tree)對象。之後 Git 創建的提交對象,除了包含相關提交信息以外,還包含着指向這個樹對象(項目根目錄)的指針,如此它就可以在將來需要的時候,重現此次快照的內容了。
現在,Git 倉庫中有五個對象:
三個表示文件快照內容的 blob 對象;一個記錄着目錄樹內容及其中各個文件對應 blob 對象索引的 tree 對象;以及一個包含指向 tree 對象(根目錄)的索引和其他提交信息元數據的 commit 對象。
概念上來說,倉庫中的各個對象保存的數據和相互關係看起來如圖 所示:
單個提交對象在倉庫中的數據結構
作些修改後再次提交,那麼這次的提交對象會包含一個指向上次提交對象的指針(譯註:即下圖中的 parent 對象)。兩次提交後,倉庫歷史會變成圖 :
多個提交對象之間的鏈接關係
現在來談分支。
Git 中的分支,其實本質上僅僅是個指向 commit 對象的可變指針。Git 會使用 master 作爲分支的默認名字。在若干次提交後,你其實已經有了一個指向最後一次提交對象的 master 分支,它在每次提交的時候都會自動向前移動。
分支其實就是從某個提交對象往回看的歷史
那麼,Git 又是如何創建一個新的分支的呢?答案很簡單,創建一個新的分支指針。比如新建一個 testing 分支,可以使用 git branch
命令:
$ git branch testing
這會在當前 commit 對象上新建一個分支指針。
多個分支指向提交數據的歷史
那麼,Git 是如何知道你當前在哪個分支上工作的呢?其實答案也很簡單,它保存着一個名爲 HEAD 的特別指針。
請注意它和你熟知的許多其他版本控制系統(比如 Subversion 或 CVS)裏的 HEAD 概念大不相同。在 Git 中,它是一個指向你正在工作中的本地分支的指針(譯註:將 HEAD 想象爲當前分支的別名。)。運行 git branch
命令,僅僅是建立了一個新的分支,但不會自動切換到這個分支中去,所以在這個例子中,我們依然還在 master 分支裏工作(參考圖 3-5)。
HEAD 指向當前所在的分支
要切換到其他分支,可以執行 git checkout
命令。我們現在轉換到新建的 testing 分支:
$ git checkout testing
這樣 HEAD 就指向了 testing 分支。
HEAD 在你轉換分支時指向新的分支
這樣的實現方式會給我們帶來什麼好處呢?好吧,現在不妨再提交一次:
$ vim test.rb
$ git commit -a -m 'made a change'
提交後的結果:
每次提交後 HEAD 隨着分支一起向前移動
非常有趣,現在 testing 分支向前移動了一格,而 master 分支仍然指向原先 git checkout
時所在的 commit 對象。現在我們回到 master 分支看看:
$ git checkout master
顯示結果:
HEAD 在一次 checkout 之後移動到了另一個分支
這條命令做了兩件事。它把 HEAD 指針移回到 master 分支,並把工作目錄中的文件換成了 master 分支所指向的快照內容。也就是說,現在開始所做的改動,將始於本項目中一個較老的版本。它的主要作用是將 testing 分支裏作出的修改暫時取消,這樣你就可以向另一個方向進行開發。
我們作些修改後再次提交:
$ vim test.rb
$ git commit -a -m 'made other changes'
現在我們的項目提交歷史產生了分叉,因爲剛纔我們創建了一個分支,轉換到其中進行了一些工作,然後又回到原來的主分支進行了另外一些工作。這些改變分別孤立在不同的分支裏:我們可以在不同分支裏反覆切換,並在時機成熟時把它們合併到一起。而所有這些工作,僅僅需要branch
和 checkout
這兩條命令就可以完成。
不同流向的分支歷史
由於 Git 中的分支實際上僅是一個包含所指對象校驗和(40 個字符長度 SHA-1 字串)的文件,所以創建和銷燬一個分支就變得非常廉價。說白了,新建一個分支就是向一個文件寫入 41 個字節(外加一個換行符)那麼簡單,當然也就很快了。
這和大多數版本控制系統形成了鮮明對比,它們管理分支大多采取備份所有項目文件到特定目錄的方式,所以根據項目文件數量和大小不同,可能花費的時間也會有相當大的差別,快則幾秒,慢則數分鐘。
而 Git 的實現與項目複雜度無關,它永遠可以在幾毫秒的時間內完成分支的創建和切換。
同時,因爲每次提交時都記錄了祖先信息(譯註:即 parent
對象),將來要合併分支時,尋找恰當的合併基礎(譯註:即共同祖先)的工作其實已經自然而然地擺在那裏了,所以實現起來非常容易。
Git 鼓勵開發者頻繁使用分支,正是因爲有着這些特性作保障。