分支和合并

Git 跟其他版本控制系統***的優勢就在于其高級的分支模型。

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

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

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

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

當然，也有一些其他的系統可以部分實現上述的功能和優勢，只是具體的執行會變的困難和容易出錯。Git 讓這些工作變得難以置信的簡單，它在開發者學習其使用的同時就改變了開發者的工作模式。

輕量和快速

Git 很快。Git 基本上所有的操作都在本地執行，這對于那些必須跟服務器通信的集中式系統是一個巨大的速度優勢。

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

壓力測試

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

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

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

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

你需要注意的是，這已經是 SVN ***的運行場景了 — 一個沒有任何負載的服務器，客戶端和服務器之間的網絡帶寬達到 80MB/s。上文中的所有指標在受網絡波動，或者在一個更差的網絡環境下 SVN 的表現都更差，然而 Git 這邊幾乎所有的指標都不受影響。

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

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

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

分布式

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

多個備份

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

任意工作流

因為 Git 擁有分布式特性和極好的分支系統，你可以在此基礎上輕松實現大量的工作流模型。

Subversion（SVN） 風格工作流

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

整合管理者工作流

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

維護者和負責人工作流

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

數據校驗

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

在不改變 ID（校驗和）的情況下也不可能出現改變任何文件，日期，提交說明或者任何其他在 Git 倉庫中的數據。這就意味著，如果你有一個 commit ID，你不但可以確定這個版本的代碼跟他提交的時候是一模一樣的，而且這個版本之前的歷史也沒有發生任何改變。

大多數中央存儲的版本控制系統默認不提供這樣的校驗整合。

暫存區域

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

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

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

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

免費和開源

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

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