我會做這個(gè)網(wǎng)站是因?yàn)槲一撕芏鄷r(shí)間在替 Gitsters 辯護(hù)，對抗那些狂熱者
(fanboyism)，從眾者 (badwagonism) 還有 koolaid-thirst。這裡要說明的就是為什麼大家都要從 X 換成
Git，而為什麼你也應(yīng)該這樣做的原因。直接點(diǎn)擊任何一個(gè)原因來展開查看。
使 Git 從幾乎所有其他 SCM 中脫穎而出，最受矚目的特色，恐怕非它的分支模型莫屬。
它完全不同於我在此一起比較的其他模型，大部分它們推薦的最佳分支方法僅僅只是複製倉儲 (repository) 到新的目錄而已。
Git 可不這麼做。 Git
讓你可以擁有多個(gè)本地的分支，它們可能是完全獨(dú)立的，而且建立、合併和刪除這些開發(fā)的支線只需要幾秒鐘的時(shí)間。
這表示你可以這樣做：
最重要的是，當(dāng)你要發(fā)布到一個(gè)遠(yuǎn)端的倉儲，你不需要把你所有的分支都推出去。
你可以只分享你的分支的其中一個(gè)而不是全部。這讓大家可以嘗試新的點(diǎn)子而不需要擔(dān)心要計(jì)劃要如何、何時(shí)合併或與其他人分享。
你在其他系統(tǒng)上可以找到方法做同樣的事，但是會比較困難且容易出錯(cuò)。 Git
讓這個(gè)過程變得非常簡單，而且當(dāng)開發(fā)人員開始學(xué)習(xí)，它常常會改變他們工作的方法。
svn perforce
這基本上對所有分散式 SCM 來說都是一樣的，但是在我的經(jīng)驗(yàn)中 Git 把這個(gè)特性發(fā)揮的更好。 除了
'fetch', 'pull' 和 'push' 這些命
令外，幾乎沒有其他命令會需要硬碟之外的東西。
這不只讓大部分操作變得比你可能習(xí)慣的還要快得多，它還讓你可以離線工作。
這聽起來也許沒有什麼，但是我總是驚訝於我有多麼常離線工作。
當(dāng)你在飛機(jī)上或火車上，你還可以建立分支、合併和提交工作、瀏覽專案的歷史，這是多麼的有生產(chǎn)力。
 就算是用 Mercurial，一些常用的指令如 'incoming' 和 'outgoing'
也需要連線伺服器，而用 Git 你可以在離線前 'fetch'
伺服器上所有的資料，然後比較、合併和查看紀(jì)錄，這些資料原本是在伺服器上還沒有在你的本分支中的。
這表示你可以很容易擁有不只你自己的分支的副本，還有其他任何和你一起工作的人的分支都可以存在你的 Git
倉儲中而不打亂你原有的東西。
Git 很快。大家都這麼說，甚至那些其他系統(tǒng)的死忠支持者也都會給予 Git 這個(gè)評價(jià)。 使用
Git，所有的操作都是在本地端的特性讓它比 SVN 與 Perforce 跑得快許多，它們兩個(gè)都需要網(wǎng)路連線才能完成大部分操作。
然而，就算是與其他也是在本地端操作的 DSCM 比較，Git 還是快非常多。
一部分的原因可能是因?yàn)樗墙碛迷?Linux 核心上的，這表示它從一開始就必須有效率的處理非常大的倉儲。
此外，因?yàn)?Git 是用 C 寫的，減少了使用其他高階語言在執(zhí)行期的開銷。 另外一個(gè) Git
這麼快地原因是因?yàn)樗闹饕_發(fā)者們將這個(gè)列為設(shè)計(jì)的目標(biāo)。
底下是一些我測試的數(shù)據(jù)，使用 Django 的原始碼倉儲與三種不同的 SCM： Git, Mercurial
和 Bazaar。 我也用 SVN 測試了一些同樣的項(xiàng)目，不過相信我，它慢更多 — 基本上是 Bazaar 的數(shù)字再加上網(wǎng)路的延遲...
測試的結(jié)果是所有操作，除了加新檔案之外都是 Git 最快。 (還有大量的提交操作，Hg
基本上一樣快，可是我測試的提交量是如此之大，你平常不太可能有同樣的的量 — 正常的提交操作在 Git 快多了。)
Cold 和 Hot 分支數(shù)字是我第一次和第二次分支一個(gè)倉儲 — 第二次分支的數(shù)據(jù)有使用磁碟快取。
要特別注意的是雖然 'add' 操作的速度慢很多，但這是在大量的檔案 — 超過 2000 個(gè) —
上進(jìn)行新增操作 。 對於大部分人日常使用來說，在任何系統(tǒng)上新增操作都只會用到幾分之一秒而已。 其他測試到的操作 (除了大量提交...大概)
應(yīng)該與你日常用到的差不多。
這些數(shù)字不會很難重現(xiàn)，只要用不同的系統(tǒng) clone 一份 Django 計(jì)劃然後試試這些指令就可以了。
Git 真的很懂得怎麼節(jié)省磁碟空間。 你的 Git 目錄只會 (一般來說) 比一個(gè) SVN checkout
大一點(diǎn)點(diǎn) — 一些情況下甚至更小 (顯然 .svn 目錄裡面有很多東西可以丟掉)。
以下數(shù)據(jù)是用不同系統(tǒng)使用同樣的歷史紀(jì)錄點(diǎn)取出 Django 之後得到。
* 第二個(gè) Bzr 數(shù)字是我執(zhí)行 'bzr pack'
後得到，我原本以為會讓它更小，結(jié)果反而讓它變大許多...。
hg bzr svn perforce
和其他系統(tǒng)不一樣，Git 有它稱為 "staging area" 或 "index" 的東西。
這是一個(gè)中間地帶讓你可以在提交前設(shè)定你想要提交什麼。
Staging area 最酷的地方，讓 Git 遠(yuǎn)遠(yuǎn)拋開其他工具的，就是你可以輕易的 在工作告一段落後
stage 一些你的檔案，然後提交上去而不需要提交所有修改過的檔案，或是必須在命令列上列出所有想要提交的檔案。
 這還允許你只 stage 修改過的檔案的一部分。
想像有一天你對一個(gè)檔案做了兩項(xiàng)毫不相關(guān)的修改，然後你發(fā)現(xiàn)忘了先提交其中一個(gè)。 現(xiàn)在你可以只 stage 你現(xiàn)在要提交的部份，然後在 stage
剩下的改變給下一次提交。 這個(gè)功能可擴(kuò)大應(yīng)用到任何你對檔案的改變。
當(dāng)然了，Git 也可以很簡單的略過這些特性。 如果你不想要控制這麼多 — 只要加上 '-a' 到你的
commit 命令就可以一次把所有的修改都丟到 staging area 去。
svn perforce
任何分散式 SCM，當(dāng)然包括 Git，最酷的功能之一就是它是分散式的。 這表示你不是只 "checkout"
目前最新版的原始碼，而是 "clone" 整個(gè)倉儲。
這表示甚至你是使用中央集中式的工作流程，每一位使用者都有會一份主伺服器的備份，每一份都可以在主伺服器當(dāng)機(jī)或損
壞時(shí)推上去取代主伺服器。 基本上使用 Git 不會因?yàn)檫z失單一的點(diǎn)而造成災(zāi)難，除非就只有那一個(gè)點(diǎn)。
而且這不會使得操作變慢太多。平均來說，一次 SVN 的 checkout 只比其他 DSCM 快一點(diǎn)。
當(dāng)然在我測試過的 DSCM 中，Git 是最快的。
svn perforce
其中一個(gè) Git
令人驚訝的事情就是因?yàn)樗姆稚⑹皆O(shè)計(jì)以及超級分支系統(tǒng)，你可以輕易的實(shí)做出幾乎任何你想得到的工作流程。
Subversion 式的工作流程這是一種很常見的 Git
工作流程，特別是那些從集中管理式系統(tǒng)轉(zhuǎn)換過來的人會使用的，是一種集中管理式的工作流程。 如果在你最後一次 fetch 後有人發(fā)布過改變，Git
不會允許你跟著發(fā)布，所以使用這種集中式的模型，所有的開發(fā)人員都發(fā)布到同一個(gè)伺服器也可以工作的很好。
整合管理員工作流程另外一種常見的 Git 工作流程就是有一個(gè)整合管理員 — 一個(gè)負(fù)責(zé)提交到 'blessed'
倉儲的人，然後其他數(shù)位開發(fā)人員從這個(gè)倉儲複製，發(fā)布到他們自己的獨(dú)立倉儲去，然後要求整合者 pull 他們的修改。 這是在開放原始碼界或是
GitHub 倉儲上常見的開發(fā)模型。
司令官與副手的工作流程對於一些更複雜的專案，你可以讓你的開發(fā)人員們使用類似於 Linux
核心的開發(fā)流程，開發(fā)人員們各自負(fù)責(zé)專案中不同的子系統(tǒng) (副手) 然後合併所有關(guān)於此子系統(tǒng)的改變。另外一位整合者 (司令官) 只可以從他的副手手上
pull 改變，然後發(fā)布到 'blessed' 倉儲讓所有人都可以複製回去。
在一次的，Git 是完全非常有彈性的，所以你可以混合和取用適合你的工作流程。
hg bzr svn perforce
這由我來說可能有點(diǎn)偏頗，因?yàn)槲姨?nbsp;GitHub 工作，但是我還是決定要寫這一部份，因?yàn)楹芏嗳苏f他們是因?yàn)?GitHub
而選擇 Git。
GitHub 是很多人使用 Git 的原因之一，因?yàn)樗袷且粋€(gè)社交網(wǎng)路而不僅僅是簡單的 hosting
服務(wù)。 人們找到其他開發(fā)人員或是專案，和他們想要做的事類似，因此可以輕易的分支然後貢獻(xiàn)，以 Git 和各種專案為中心創(chuàng)造出一個(gè)非?；钴S的社群。
網(wǎng)路上還有其他類似的服務(wù)，有 Git 的也有其他 SCM
的，但是很少是使用者導(dǎo)向或社交導(dǎo)向的，沒有一個(gè)其他服務(wù)有類似的用戶群。 這個(gè) GitHub 的社交觀點(diǎn)是它的殺手級應(yīng)用，合併以上的特色使得使用
Git 與 GitHub 工作變成快速開發(fā)開放原始碼專案的極佳組合。
這樣的社群不是其他 SCM 所擁有的。
perforce
這本來不是真的 — 早期 Git 不是一個(gè)真正的
SCM，比較像是一組工具讓你可以用分散式的觀點(diǎn)做出有版本控制的檔案系統(tǒng)。 但是現(xiàn)在，Git 的命令集以及學(xué)習(xí)曲線已經(jīng)變得和其他 SCM
類似，甚至比一些更好。
不特別去做研究的話很難證明這一點(diǎn)，我在這僅顯示出 Mercurial 與 Git 的預(yù)設(shè) 'help'
菜單之間的差異。 我把兩個(gè)系統(tǒng)間相同 (或是近似) 的命令做了高亮顯示。 (在 Hg 中，如果你輸入 'hg help'，你會得到一個(gè) 40
多個(gè)指令的清單。)
在 Git 1.6 之前，所有的 Git 命令都放在執(zhí)行檔路徑下，常使一些人的感到迷惑。 現(xiàn)在雖然 Git
仍然認(rèn)識這些指令，但在執(zhí)行檔路徑下的命令只剩下 'git' 一個(gè)。 如果你仔細(xì)比較 Mercurial 和 Git 會發(fā)現(xiàn)，Git 和
Mercurial 有幾乎一樣的指令集和說明系統(tǒng) — 以初學(xué)者的 UI 角度來說兩者之間幾乎沒有差別?，F(xiàn)在已經(jīng)很難說 Mercurial 或
Bzr 比 Git 容易學(xué)習(xí)了。
|
|
|
