分支和合并

Git 跟其他版本控制系統(tǒng)最大的優(yōu)勢就在于其高級的分支模型。

Git 允許而且 鼓勵 你在本地使用多個完全獨立的分支。這些分支的創(chuàng)建，合并和刪除幾乎都可以在幾秒內(nèi)完成。

這意味著你可以輕松的做如下操作：

• 無痛的上下文切換 創(chuàng)建分支試驗一個想法，提交幾次，切回你原來分支的狀態(tài)，應(yīng)用一個改動 patch，切回你原來正在試驗的狀態(tài)，將剛才應(yīng)用的 patch 合并過來。
• 基于角色的代碼支線 你可能會有一個分支僅僅包含那些只存在于生產(chǎn)環(huán)境上的代碼，另外有一個獨立的分支用以合并測試環(huán)境代碼，還有若干個更小一些的分支用于日常開發(fā)工作
• 基于特性的工作流 為每一個新的特性創(chuàng)建新的分支，你可以方便平滑的在這些分支之間無縫切換，當(dāng)這些特性的改動完成的時候，你可以將其合并入主分支，并把特性分支刪掉。
• 任意試驗 創(chuàng)建一個分支專門用來試驗，當(dāng)覺得試驗不理想的時候，直接刪除掉即可，放棄掉之前的試驗內(nèi)容。這時候不會有任何其他人察覺到這個試驗（甚至在這期間你還可以推送其他不相關(guān)的分支）

尤其是當(dāng)你推送至遠程倉庫的時候，你不必推送所有分支，你可以選擇只推送少數(shù)你愿意分享的分支，當(dāng)然如果你愿意，也可以推送所有分支。這一點傾向于讓開發(fā)者在試驗很多新的想法的時候免除發(fā)布自己的未成熟的試驗計劃的顧慮。

當(dāng)然，也有一些其他的系統(tǒng)可以部分實現(xiàn)上述的功能和優(yōu)勢，只是具體的執(zhí)行會變的困難和容易出錯。Git 讓這些工作變得難以置信的簡單，它在開發(fā)者學(xué)習(xí)其使用的同時就改變了開發(fā)者的工作模式。

輕量和快速

Git 很快。Git 基本上所有的操作都在本地執(zhí)行，這對于那些必須跟服務(wù)器通信的集中式系統(tǒng)是一個巨大的速度優(yōu)勢。

Git 一開始是為了管理 Linux Kernel 的源代碼設(shè)計的，這意味著他從第一天誕生就擁有了處理大型倉庫的高效優(yōu)勢。Git 使用 C 語言編寫，減輕了使用更高級別編程語言的 Runtime 帶來的性能損耗。Git 最開始的兩個重要的設(shè)計目標(biāo)就是性能和速度。

壓力測試

讓我們看一下與 SVN （一個通用的集中式存儲版本控制系統(tǒng)，跟 CVS 和 Perforce 很像）相比下的常規(guī)操作的性能測試指標(biāo)。這里指標(biāo)是值越小，速度越快。

為了測試，我們在亞馬遜的 AWS 的同樣的可用區(qū)上新建了兩個 Large 類型的計算服務(wù)器實例。每一個計算實例上都安裝 Git 和 SVN。 我們把 Ruby 的源代碼倉庫拷貝到了 Git 和 SVN 的計算服務(wù)器示例上，兩者都執(zhí)行通用的操作。

在有些情況下，兩者的命令和實際效果并不能完全對應(yīng)起來。在這里，我們在常用的操作中選擇相似效果的匹配情況。例如，對于“提交”的測試，在 Git 中我們也是計算 Push 的時間的。然而在大多數(shù)情況下，你可能實際上并不會在提交后馬上就推送到服務(wù)器上，這在 SVN 上是不可分割的操作。

下面表格中所有的時間單位都是秒。

你需要注意的是，這已經(jīng)是 SVN 最好的運行場景了 -- 一個沒有任何負載的服務(wù)器，客戶端和服務(wù)器之間的網(wǎng)絡(luò)帶寬達到 80MB/s。上文中的所有指標(biāo)在受網(wǎng)絡(luò)波動，或者在一個更差的網(wǎng)絡(luò)環(huán)境下 SVN 的表現(xiàn)都更差，然而 Git 這邊幾乎所有的指標(biāo)都不受影響。

很明顯，在這些最常用的版本控制工具的操作中，甚至是在SVN 的理想使用環(huán)境下，**Git 在很多方面都大幅領(lǐng)先**。

一個 Git 比 SVN 慢的地方是初始化 clone 倉庫。在這種情況下，Git 是在下載整個倉庫歷史而不是僅僅是最新版本的代碼。上文中的表格所示，僅僅執(zhí)行一次的操作影響并不是很大。

另外一個有趣的點是，Git 和 SVN 在 Clone 或者 Checkout 到本地后的文件大小幾乎差別不大，要知道對于 Git 來說，本地可是包含了整個項目歷史。這也展示了 Git 在文件壓縮和存儲上的超高效率。

分布式

Git 最棒的特性之一就是分布式。這意味著，你要 clone 整個倉庫而不是僅僅 checkout 分支的最新頭部版本。

多個備份

在日常的使用場景中 Git 往往有多個備份。這意味著就算在使用一個中央存儲式的工作流，每一個用戶都在本地有一個服務(wù)器上的完整備份。這里的任意一個版本都可以在服務(wù)器端數(shù)據(jù)損壞或者丟失的時候推送回服務(wù)器以挽救損失。事實上，只要你的倉庫不是只有一個 copy，Git 就不會存在單點問題。

任意工作流

因為 Git 擁有分布式特性和極好的分支系統(tǒng)，你可以在此基礎(chǔ)上輕松實現(xiàn)大量的工作流模型。

Subversion（SVN） 風(fēng)格工作流

集中式存儲的工作流非常常見，特別是對于那些從傳統(tǒng)的集中式代碼版本管理系統(tǒng)轉(zhuǎn)過來使用 Git 的人。Git 一樣可以提供這種工作形式：每次 Push 必須要更新到遠程倉庫的最新版本。所以說大家還是像以前一樣使用集中式存儲的工作流往同一個服務(wù)器上 Push 代碼依然沒問題。

整合管理者工作流

另外一個常見的 Git 工作流是整合工作流。主要的倉庫有一個單一的開發(fā)者維護（維護者）。其他若干開發(fā)者從這個倉庫 clone，然后推送到他們自己的完全獨立的倉庫里面，最后請求維護者從主要倉庫 Pull 那些他們在各自的倉庫里面的改動。這種形式往往在 GitHub 上以開源的形式進行協(xié)作。

維護者和負責(zé)人工作流

對于一些更為復(fù)雜的項目來講，像 Linux 內(nèi)核這樣的開發(fā)工作流也是很有效的。在這個模型中，負責(zé)人（lieutenants）負責(zé)整個項目的一些特定的子系統(tǒng)，他們合并所有跟那個子系統(tǒng)關(guān)聯(lián)的變動。另外一個維護者（dictator，字面理解：獨裁者）只能從他管轄的負責(zé)人這里獲取變更，并將這些變更推送到主要倉庫。然后所有人都從這個倉庫獲取更新。

數(shù)據(jù)校驗

Git 的數(shù)據(jù)模型確保了項目內(nèi)的每一個字節(jié)，每一個 bit 的一致性。提交的每一個文件都會使用校驗和計算摘要，檢出的時候也使用這個摘要值。沒有任何可能會出現(xiàn)從倉庫中獲取的內(nèi)容跟你存儲的內(nèi)容有任何差異。

在不改變 ID（校驗和）的情況下也不可能出現(xiàn)改變?nèi)魏挝募掌?，提交說明或者任何其他在 Git 倉庫中的數(shù)據(jù)。這就意味著，如果你有一個 commit ID，你不但可以確定這個版本的代碼跟他提交的時候是一模一樣的，而且這個版本之前的歷史也沒有發(fā)生任何改變。

大多數(shù)中央存儲的版本控制系統(tǒng)默認不提供這樣的校驗整合。

暫存區(qū)域

不像其他系統(tǒng)， Git 有一個概念叫做“暫存區(qū)域”或者“index”。這是一個在提交執(zhí)行之前的臨時的區(qū)域可以用來格式化和審閱改動內(nèi)容的。

一個 Git 優(yōu)于其他系統(tǒng)的功能是我們可以快速的暫存一些改動的文件，在工作目錄中只提交部分改動的文件，或者文件改動的部分內(nèi)容，以及在提交的時候在命令行里列出改動的文件列表。

暫存區(qū)域允許你僅僅暫存部分的文件改動，在你意識到你忘了提交其中一個文件之前，對文件進行兩個邏輯上不相關(guān)的修改的日子已經(jīng)一去不復(fù)返了。現(xiàn)在你可以僅僅暫存你當(dāng)前提交需要改動的文件，其他的改動在下次提交再暫存。這個特性可以擴展到對文件進行的任何更改。

當(dāng)然，Git 也允許你忽略掉暫存區(qū)域這個過程，你可以輕松的在 commit 命令后面添加 '-a' 選項來直接將所有改動提交。Git 會自動幫你先暫存到暫存區(qū)域，再執(zhí)行提交。

免費和開源

Git 是一個使用 GNU GPL2.0 協(xié)議的開源軟件。Git 選擇 GPLv2 來確保你可以自由的分享和改造自由軟件，而且能確保使用它的任何用戶都是自由免費的。

然而，我們確實也保留了 “Git” 和 logos 避免爭議。欲知詳情請看我們的商標(biāo)政策。

譯者注

本文譯自 Git 官方網(wǎng)站的關(guān)于說明