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