關(guān)于Git你需要知道的一些事情
分支和合并
Git 跟其他版本控制系統(tǒng)***的優(yōu)勢就在于其高級的分支模型。
Git 允許而且 鼓勵 你在本地使用多個完全獨(dú)立的分支。這些分支的創(chuàng)建，合并和刪除幾乎都可以在幾秒內(nèi)完成。
這意味著你可以輕松的做如下操作：
- 無痛的上下文切換 創(chuàng)建分支試驗(yàn)一個想法，提交幾次，切回你原來分支的狀態(tài)，應(yīng)用一個改動 patch，切回你原來正在試驗(yàn)的狀態(tài)，將剛才應(yīng)用的 patch 合并過來。
- 基于角色的代碼支線 你可能會有一個分支僅僅包含那些只存在于生產(chǎn)環(huán)境上的代碼，另外有一個獨(dú)立的分支用以合并測試環(huán)境代碼，還有若干個更小一些的分支用于日常開發(fā)工作
- 基于特性的工作流 為每一個新的特性創(chuàng)建新的分支，你可以方便平滑的在這些分支之間無縫切換，當(dāng)這些特性的改動完成的時候，你可以將其合并入主分支，并把特性分支刪掉。
- 任意試驗(yàn) 創(chuàng)建一個分支專門用來試驗(yàn)，當(dāng)覺得試驗(yàn)不理想的時候，直接刪除掉即可，放棄掉之前的試驗(yàn)內(nèi)容。這時候不會有任何其他人察覺到這個試驗(yàn)（甚至在這期間你還可以推送其他不相關(guān)的分支）
尤其是當(dāng)你推送至遠(yuǎn)程倉庫的時候，你不必推送所有分支，你可以選擇只推送少數(shù)你愿意分享的分支，當(dāng)然如果你愿意，也可以推送所有分支。這一點(diǎn)傾向于讓開發(fā)者在試驗(yàn)很多新的想法的時候免除發(fā)布自己的未成熟的試驗(yàn)計劃的顧慮。
當(dāng)然，也有一些其他的系統(tǒng)可以部分實(shí)現(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ù)器實(shí)例。每一個計算實(shí)例上都安裝 Git 和 SVN。 我們把 Ruby 的源代碼倉庫拷貝到了 Git 和 SVN 的計算服務(wù)器示例上，兩者都執(zhí)行通用的操作。
在有些情況下，兩者的命令和實(shí)際效果并不能完全對應(yīng)起來。在這里，我們在常用的操作中選擇相似效果的匹配情況。例如，對于“提交”的測試，在 Git 中我們也是計算 Push 的時間的。然而在大多數(shù)情況下，你可能實(shí)際上并不會在提交后馬上就推送到服務(wù)器上，這在 SVN 上是不可分割的操作。
下面表格中所有的時間單位都是秒。
| 操作 | 描述 | Git | SVN | 性能倍數(shù) |
|---|---|---|---|---|
| 提交文件 (A) | Add, commit and push 113 modified files (2164+, 2259-) | 0.64 | 2.60 | 4x |
| 提交圖片 (B) | Add, commit and push 1000 1k images | 1.53 | 24.70 | 16x |
| 對比當(dāng)前變動 | Diff 187 changed files (1664+, 4859-) against last commit | 0.25 | 1.09 | 4x |
| 對比最近的變動 | Diff against 4 commits back (269 changed/3609+,6898-) | 0.25 | 3.99 | 16x |
| 對比標(biāo)簽 | Diff two tags against each other (v1.9.1.0/v1.9.3.0 ) | 1.17 | 83.57 | 71x |
| 提交歷史 (50) | Log of the last 50 commits (19k of output) | 0.01 | 0.38 | 31x |
| 提交歷史 (全部) | Log of all commits (26,056 commits – 9.4M of output) | 0.52 | 169.20 | 325x |
| 提交歷史 (文件) | Log of the history of a single file (array.c – 483 revs) | 0.60 | 82.84 | 138x |
| 更新 | Pull of Commit A scenario (113 files changed, 2164+, 2259-) | 0.90 | 2.82 | 3x |
| Blame | Line annotation of a single file (array.c) | 1.91 | 3.04 | 1x |
你需要注意的是，這已經(jīng)是 SVN ***的運(yùn)行場景了 — 一個沒有任何負(fù)載的服務(wù)器，客戶端和服務(wù)器之間的網(wǎng)絡(luò)帶寬達(dá)到 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（Shallow Clone） | Git | SVN |
|---|---|---|---|---|
| Clone | Git Clone 以及 shallow clone(淺 clone) vs SVN checkout | 21.0 | 107.5 | 14.0 |
| 大小(M) | 客戶端在 clone/checkout 后的文件大小 (以 M 為單位) | 181.0 | 132.0 |
另外一個有趣的點(diǎn)是，Git 和 SVN 在 Clone 或者 Checkout 到本地后的文件大小幾乎差別不大，要知道對于 Git 來說，本地可是包含了整個項(xiàng)目歷史。這也展示了 Git 在文件壓縮和存儲上的超高效率。
分布式
Git 最棒的特性之一就是分布式。這意味著，你要 clone 整個倉庫而不是僅僅 checkout 分支的***頭部版本。
多個備份
在日常的使用場景中 Git 往往有多個備份。這意味著就算在使用一個中央存儲式的工作流，每一個用戶都在本地有一個服務(wù)器上的完整備份。這里的任意一個版本都可以在服務(wù)器端數(shù)據(jù)損壞或者丟失的時候推送回服務(wù)器以挽救損失。事實(shí)上，只要你的倉庫不是只有一個 copy，Git 就不會存在單點(diǎn)問題。
任意工作流
因?yàn)?Git 擁有分布式特性和極好的分支系統(tǒng)，你可以在此基礎(chǔ)上輕松實(shí)現(xiàn)大量的工作流模型。
Subversion（SVN） 風(fēng)格工作流
集中式存儲的工作流非常常見，特別是對于那些從傳統(tǒng)的集中式代碼版本管理系統(tǒng)轉(zhuǎn)過來使用 Git 的人。Git 一樣可以提供這種工作形式：每次 Push 必須要更新到遠(yuǎn)程倉庫的***版本。所以說大家還是像以前一樣使用集中式存儲的工作流往同一個服務(wù)器上 Push 代碼依然沒問題。
整合管理者工作流
另外一個常見的 Git 工作流是整合工作流。主要的倉庫有一個單一的開發(fā)者維護(hù)（維護(hù)者）。其他若干開發(fā)者從這個倉庫 clone，然后推送到他們自己的完全獨(dú)立的倉庫里面，***請求維護(hù)者從主要倉庫 Pull 那些他們在各自的倉庫里面的改動。這種形式往往在 GitHub 上以開源的形式進(jìn)行協(xié)作。
維護(hù)者和負(fù)責(zé)人工作流
對于一些更為復(fù)雜的項(xiàng)目來講，像 Linux 內(nèi)核這樣的開發(fā)工作流也是很有效的。在這個模型中，負(fù)責(zé)人（lieutenants）負(fù)責(zé)整個項(xiàng)目的一些特定的子系統(tǒng)，他們合并所有跟那個子系統(tǒng)關(guān)聯(lián)的變動。另外一個維護(hù)者（dictator，字面理解：獨(dú)裁者）只能從他管轄的負(fù)責(zé)人這里獲取變更，并將這些變更推送到主要倉庫。然后所有人都從這個倉庫獲取更新。
數(shù)據(jù)校驗(yàn)
Git 的數(shù)據(jù)模型確保了項(xiàng)目內(nèi)的每一個字節(jié)，每一個 bit 的一致性。提交的每一個文件都會使用校驗(yàn)和計算摘要，檢出的時候也使用這個摘要值。沒有任何可能會出現(xiàn)從倉庫中獲取的內(nèi)容跟你存儲的內(nèi)容有任何差異。
在不改變 ID（校驗(yàn)和）的情況下也不可能出現(xiàn)改變?nèi)魏挝募?，日期，提交說明或者任何其他在 Git 倉庫中的數(shù)據(jù)。這就意味著，如果你有一個 commit ID，你不但可以確定這個版本的代碼跟他提交的時候是一模一樣的，而且這個版本之前的歷史也沒有發(fā)生任何改變。
大多數(shù)中央存儲的版本控制系統(tǒng)默認(rèn)不提供這樣的校驗(yàn)整合。
暫存區(qū)域
不像其他系統(tǒng)， Git 有一個概念叫做“暫存區(qū)域”或者“index”。這是一個在提交執(zhí)行之前的臨時的區(qū)域可以用來格式化和審閱改動內(nèi)容的。
一個 Git 優(yōu)于其他系統(tǒng)的功能是我們可以快速的暫存一些改動的文件，在工作目錄中只提交部分改動的文件，或者文件改動的部分內(nèi)容，以及在提交的時候在命令行里列出改動的文件列表。
暫存區(qū)域允許你僅僅暫存部分的文件改動，在你意識到你忘了提交其中一個文件之前，對文件進(jìn)行兩個邏輯上不相關(guān)的修改的日子已經(jīng)一去不復(fù)返了。現(xiàn)在你可以僅僅暫存你當(dāng)前提交需要改動的文件，其他的改動在下次提交再暫存。這個特性可以擴(kuò)展到對文件進(jìn)行的任何更改。
當(dāng)然，Git 也允許你忽略掉暫存區(qū)域這個過程，你可以輕松的在 commit 命令后面添加 ‘-a’ 選項(xiàng)來直接將所有改動提交。Git 會自動幫你先暫存到暫存區(qū)域，再執(zhí)行提交。
免費(fèi)和開源
Git 是一個使用 GNU GPL2.0 協(xié)議的開源軟件。Git 選擇 GPLv2 來確保你可以自由的分享和改造自由軟件，而且能確保使用它的任何用戶都是自由免費(fèi)的。
