【導讀】：十年前的這一周，Linux 內(nèi)核開發(fā)社區(qū)正面臨嚴峻的挑戰(zhàn)：他們不能繼續(xù)使用 BitKeeper 了（注：原因是當時Bitkeeper 著作權(quán)所有者決定收回授權(quán)，內(nèi)核開發(fā)團隊與其協(xié)商無果），而又沒有其他的 SCM （Software Configuration Management）可滿足他們的分布式系統(tǒng)的需求。Linux 之父 Linus Torvalds 接受了這個挑戰(zhàn)，決定開發(fā)一個新的版本控制系統(tǒng)。周末他消失了，新的一周，Git 問世了。今天，Git 已經(jīng)成為上萬個項目的版本控制系統(tǒng)，并且在程序員中引發(fā)了開源熱潮。
為了慶祝里程碑式的一刻，Linux 基金會邀請了 Linus 來分享 Git 背后的故事，以及他對 Git 在軟件開發(fā)中的影響的觀點。
Linus Torvalds
你為什么要開發(fā) Git？
Torvalds：我從來沒有想過去做版本控制軟件，因為在我看來那是計算機世界里最無聊的事了（如果數(shù)據(jù)庫除外的話 ;^），我天生就不喜歡 SCM。但是 Bitkeeper 的誕生改變了我對版本控制的認識。BK 在大多數(shù)方面是正確的，在本地保存一個倉庫的副本，分布式合并確實是一大創(chuàng)新。這個分布式版本控制的創(chuàng)新完美地解決了 SCM 的通�。�“誰可以修改代碼”的難題。BK 告訴我們，你只要給每個人一個倉庫，問題就解決了。但是 BK 也存在一些問題，技術(shù)上的問題（例如重命名很麻煩）還不算什么，它最大的壞處是不開源，很多人因為這個不使用它。所以即使我們有幾個核心維護者使用 BK——開源項目可以免費使用——但它也沒有普及。雖然它幫助過我們開發(fā)內(nèi)核，但依然有不少痛點沒有解決。
當 Tridge 違反 BK 的使用協(xié)議反編譯 BK 的時候，我們到達了緊急關(guān)頭。我花了幾個周（還是幾個月來著？）試圖調(diào)解 Tridge 和 Larry McVoy（伯樂在線注：他是 Bitkeeper 的 老大），最后也沒有成功。我意識到我不能繼續(xù)使用 BK 了，但我真的不想回到?jīng)]有 BK 的黑暗時代。遺憾的是，我們想用其他 SCM 來代替它，卻沒有找到能在遠程方面工作得好的�，F(xiàn)有的軟件不能滿足我對遠程方面的需求，我又擔心整個流程和代碼的完整性，所以最后我決定自己寫一個。
你怎么做到的？整個周末都在熬夜寫這個，還是只用了常規(guī)的時間？
T：呵呵，其實可以在 Git 的源代碼倉庫中看它是如何成型的。除了第一天的工作，因為我花了一天的時間進入“自舉(self-hosting)”。之后我就能使用 Git 向 Git 自己提交代碼了，雖然第一天所有的東西都不是明確的，但是大體上也都在那里了。雖然這些工作大多是在白天完成的，但也有時候工作到了深夜，甚至有兩天到了凌晨兩點。最有趣的部分是如何將它快速成型。Git 樹中的第一次提交沒有太多代碼，但是它的基本功能已經(jīng)實現(xiàn)了——向它自己提交代碼。這部分寫代碼并不難，難的是如何組織數(shù)據(jù)。
所以我想強調(diào)的是，雖然它在短短十天內(nèi)就完成了（我第一次使用 git 向內(nèi)核提交代碼的時間），但是這并不是某種“馬拉松”式的開發(fā)。事實上，我早期的開發(fā)成本很低，這取決于基本的思路正確。在這個項目開始之前，我想了很久，我總結(jié)了很多別人犯過的錯誤，然后極力避免了。
Git 達到了你的期望嗎？你估計一下它現(xiàn)在工作得如何？它還有什么不足嗎？
我對 Git 很滿意。它工作得相當出色，滿足了我的所有需求。有趣的是，它還接手了很多其他項目，它成長地相當迅速。在切換版本控制系統(tǒng)中有很多惰性，看看 CVS 和 RCS 這些堅持了這么久就知道了。不過等時機到了，Git 早晚都會接管過來。
你覺得為什么它會被如此廣泛地接受？
我提過以前我為什么痛恨 SCM，我相信很多人也為相同的問題煩惱過。很多項目要改一兩個小地方就會使人抓狂。在 Git 之前，沒有東西來真正解決這個問題。人們不清楚分布式的重要性， 可能還會與此抗爭。一旦他們明白它支持的方便可靠的備份，并允許做私人的測試倉庫，而不必擔心有無中央存儲倉庫的權(quán)限的話，他們就永遠不會放棄 Git 了。
Git 會永遠流行嗎？還是你預見在將來的十年會有另一種版本控制系統(tǒng)？作者會是你嗎？
我不會是唯一一個作者，將來我們也可能使用另一種工具，但是我敢保證，它一定和 Git 非常像（“git-like”）。我不是說 Git 的什么都是對的，但它的基本路線是對的，之前其他 SCM 未曾嘗試過。
沒有假謙虛 :)
為什么 Git 能在 Linux 上工作地這么好呢？
很顯然，Git 最初是為我們的工作流程設計的，所以這是它的一部分。雖然我重復“分布式”這個詞很多次了，但這不為過。它被設計為足以高效地應付像 Linux 一樣的大項目，它也用于完成 Git 之前人們覺得“艱難”的事情——因為這些事我每天都要做。
舉個例子吧：在大多數(shù)的 SCM 中，“merging” 操作都被認為是痛苦而且艱難的事情。你需要計劃好你的合并操作，因為這涉及到很多繁瑣的細節(jié)。這我不能接受，因為我每天要做幾十次合并，即使這樣，最大的麻煩還不是合并本身，而是測試結(jié)果。“Git”的合并只需要幾秒鐘，寫合并注釋反而會花去我更多的時間。
所以 Git 基本上是為了滿足我的需求來寫的。
人們說 Git 是為聰明人設計的，即使 Andrew Morton 也說 “Git的明確設計讓你感覺你比你想象中的要蠢。”你對此的回應是什么呢？
我覺得曾經(jīng)可能是這樣的，但現(xiàn)在不再是了。人們這么想可能會有很多原因，但只有一個站得住腳，很簡單：“在 Git 中完成一件事你有太多的方法”。
使用 Git 你可以做很多事，大多數(shù)“你應該怎樣”的規(guī)則，其實并不是技術(shù)上的限制，而是建議，這樣你和別人一起工作的時候可以配合得更好。Git 是一個強大的工具，但是你不能因為這個望而卻步。雖然你可以每次用不同的方法完成相同的事情，但在多數(shù)情況下，學習 Git 的最好方法還是從最基本的事情做起。直到你熟悉基本操作了，再去接觸別的東西。（伯樂在線插播推薦幾篇文章：《Git 兩分鐘指南》、《寫給 Git 初學者的 7 個建議》、《圖解 Git /圖形化的 Git 參考手冊》、《給 Git 中級用戶的 25 個小貼士》、《讓Git 水平更上一層樓的 10 個小貼士》。）
Git 給人復雜的印象有一些歷史原因。其中一個是，它很早之前確實是復雜的。一開始需要使用 Git 來做內(nèi)核方面的工作的時候，人們要配置一些腳本。那時候的工作主要集中于讓核心模塊工作，花在易用性方面的精力很少。所以很顯然，Git 因其復雜性著稱，但那大約還是頭一年的事了。
人們認為 Git 難的原因是 Git 的與眾不同。很多人用過十幾二十年的 CVS，但 Git 并不是 CVS，一點都不像。概念不同，命令也不同。Git 從來沒有考慮過要像 CVS，甚至大行反道。所以如果你使用 CVS 之類的系統(tǒng)很長時間，就會覺得 Git 復雜，而且它的差異毫無必要。人們會對版本號碼感到奇怪。為什么 Git 的版本不像 CVS 的“1.3.1”這種遞增式的數(shù)字？為什么會是恐怖的四十位 Hex 碼？
但 Git 的不同并不是“毫無必要的”。只是這點讓人們覺得它太復雜了，因為它來自一個不同的背景。“CVS”的背景過時了�，F(xiàn)在很多程序員從沒用過 CVS，如果他們學 CVS，可能覺得 CVS 的方式太詭異了，因為他們最先學的 Git。
如果沒有 Git，Linux 內(nèi)核會發(fā)展的像現(xiàn)在這樣好嗎？為什么？
“沒有 Git”，好吧，但是一定會有別人寫出來個像 Git 的工具，一個分布式版本控制系統(tǒng)。毫無疑問，我們需要“Git”這樣的東西。
你怎么看待 Github ？
Github 是非常棒的代碼托管服務，對此我沒有任何反對。我的抱怨主要是因為它作為一個開發(fā)平臺——提交代碼，pull request，跟蹤問題等等——不夠好。不適用于內(nèi)核之類的項目。限制太多了。
部分原因是，因為內(nèi)核發(fā)展的原因，部分是因為 Github 的接口很鼓勵壞習慣。在 Github 的提交有不好的提交信息等等，就是因為接口的問題。他們確實做了改善，可能現(xiàn)在好點了，可是永遠不會適用于 Linux 內(nèi)核這樣的項目。
你見過的用 Git/Github 做的最有趣的事情是什么？
看到創(chuàng)建一個新項目能如此簡單，我很開心。以前搞代碼托管很痛苦的，但現(xiàn)在用 Git/Github ，創(chuàng)建一個小項目就小菜一碟了。你的項目是什么并不重要，重要的是你可以做得到。
你現(xiàn)在有什么精彩的項目嗎？有什么將推動軟件發(fā)展軟件嗎？
暫時沒有，如果有的話，我會告訴你。
為紀念 Git 面世十周年， Atlassian 還特別制作了一個交互信息圖，回顧了 Git 的發(fā)展歷程（各個重要里程碑）。詳情可戳：https://www.atlassian.com/git/articles/10-years-of-git/