Git 10 週年之際，創始人 Linus Torvalds 訪談

十年前的這一週，linux 核心社群面臨一個根本性的挑戰：他們不再能夠使用他們的修復控制系統：BitKeeper，同時其他的軟體配置管理遇到了對分散式系統的新需求。Linus Torvalds，Linux的創始人，將這個挑戰接手並消失了數週，創造了 Git 工具。今天 Git 被用於成千上萬個工程，並且在程式設計師社群中掀起了一個新的社會化編碼的浪潮。

為了慶祝這一里程碑，我們請 Linus 去分享 Git 的幕後故事，並且告訴我們這個工程隊軟體開發的影響。你會發現他在這個故事背後的的評論。我們跟隨者Q&A追尋Git的軌跡，同時我們為其他的工程也描繪了輪廓。去查詢KVM，Qt，Drupal，Puppet和wine背後的故事吧

為什麼開發Git?

Torvalds: 我其實根本不想做原始碼管理，我認為原始碼管理是計算機領域最無趣的事（可能資料庫更無趣 ;^）。我對SCM(原始碼管理工具)感到憤怒。但是BitKeeper的出現讓我重新認識了原始碼管理。BK (BitKeeper)大多數都是正確的,但有本地副本的儲存庫與分散式合併是一個大問題。分散式原始碼管理的一個主要問題是原始碼管理的分離——誰才可以提交改變。BK展示瞭如何通過每個人都有原始碼庫來避開這個問題。但是BK也有自己的問題：幾種技術導制了這種問題（惱火的重新命名），但最大的問題是它不開源，這讓很多人不願意使用它。因此，當我們以幾個核心的維護使用BK而告終——它們是免費使用的開源專案——但它們無處不在。BK幫助了核心開發者，但是它還是有痛點。

當Tridge (Andrew Tridgell)對（相當簡單的） BK 協議進行逆向工程–這是有悖於BK的使用規則的–的時候，事情到了不得不解決的地步。 我花了幾個星期（幾個月？我覺得是那樣）在Tridge 和 Larry McVoy之間做調解，但是到最後，明顯不起任何作用。於是，從那個時刻起，我決定不再繼續使用BK，也不願重回使用BK之前的糟透了的日子。同時，令人遺憾的是，一些其它的SCM，嘗試著做分散式的事情，但是遠端訪問也沒有處理好。我有效能的需求，不僅僅是滿足遠端可用，同時我還擔心程式碼完整性和整個工作流，於是我決定自己寫一個。

你是如何著手做這件事的?你是整個週末都在寫程式碼，還是隻在固定的幾個小時呢?

Torvalds: 嗨，實際上，你可以從git的原始碼倉庫中，檢視它是如何成型的，除了大概是最開始的一天。我大約花了一天時間來讓git“自我管控”（self-hosting），這樣，我就可以通過git來提交程式碼（commit）到git。所以大概第一天是隱藏的，但是所有其它的東西都在那裡了。編碼工作大多數在白天，但是也有少數在午夜，也有一些在凌晨2點。最有趣的部分是，它成型非常快；git樹中的第一個commit並沒有很多程式碼，但是它已經做了最基本的事情–可以提交（commit）自己。其中的技巧實際上不在於程式碼，而在於想出它如何組織資料的辦法。

所以，我想說，git在大約10天左右的時間之後的樣子（在這個點，我使用git做了*kernel*的第一次提交），它並不像某些瘋狂的垃圾編碼（而是有實際的使用價值）。早期的程式碼量實際上非常小，它的目標是正確實現基本點。 在整個專案開始之前，我一直在仔細考慮。我意識到其他人遇到的問題，也想到了要避免去做的事情。

它的存在週期達到了你的預期嗎? 你認為它目前應該如何工作呢? 是否有一些限制呢?

Torvalds: 我對git非常滿意。對於kernel的開發，它做的非常非常好，滿足了我所有的預期。讓我覺得有趣的是，它是如何接管了許多其它專案的。結果是令人吃驚的。在更換原始碼管理系統的時候，有很大的慣性；看看CVS，甚至是RCS，它們佔據了多長時間，但是，某個時刻起，git就完全接管了。

你覺得它為何如此廣泛的被採用呢?

Torvalds: 我認為，其他許多人像我一樣，都被同樣的問題弄得灰心喪氣，這些問題讓我厭惡SCM。許多專案由於試著解決一兩個邊邊角角的小問題而讓人們抓狂，並不是像git這樣真正的著手解決重要的問題。即便人們並不知曉“分散式”的部分有多麼重要（許多人曾反對它），只要他們弄明白，git允許簡單可靠的備份，同時允許人們生成他們自己私有的倉庫，而不用擔心一些中心倉庫的擁有寫訪問許可權的策略，他們是絕不會再回到以前的版本管理的。

Git會永遠存在下去嗎？或者說，您是否預見到在下一個10年中將會有其他的版本控制系統出現？你會是這個系統的作者之一嗎？

Torvalds：不，我不會是這些作者中的一員。我們在10年內或許可以看到一些新的東西，但我保證這些東西也會是“類Git”的。這並不是說Git能正確地處理所有的事情，但它以一種前所未有的方式把最為基本的問題都解決了，在這之前沒有一款軟體配置管理工具（SCM）可以與之媲美。

我可以毫不謙虛地說

為什麼Git能在Linux上工作得如此好？

Torvalds:好吧，很明顯的它就是為了我們的工作流程而設計，因此他本身就是Linux的一部分。我已經多次提到完全的“分散式”部分，但它值得一再提及。它被設計得在面對如Linux的大型專案時有足夠的效率，並且它被設計得去完成在它之前人們認為很“難”的任務——因為那些事情我每天都在做。

只舉一個例子：程式碼合併的概念在多數原始碼管理工具中通常被認為是非常痛苦和困難的事。你會計劃你的程式碼合併，因為那是重大的決定。那樣的情況對我而言不能接受，自從我一天在合併的視窗前做數十次的程式碼合併之後，最頭疼的的問題不是程式碼合併工作本身，最重要的應該是檢查其結果。Git中，程式碼合併只會花費數秒，編寫程式碼合併註釋文字卻會花費我很長的時間。

因此，Git基本上按照我的需求設計和編碼，也這樣實現。

有人說Git只是為聰明人設計的，甚至連Andrew Morton都說：“Git經過特意設計，以便讓你感到自己不夠聰明。”您對此有何回應？

Torvalds：我想在以前確實如此，但現在不同了。因為某些原因，人們覺得git難用，但我認為現在只剩一個原因，那就是：你可以用很多種方法完成一件事。

通過git你可以完成很多事請，git要求人們遵守許多規則，這些規則並非出於技術上的限制，而是為了讓人們可以更好的合作。git是一個強大的工具，開始使用時你會感覺很困難，這通常是因為你可以用不同方法完成一件事，而且這些方法都能工作！一般說來，學習git最好的方法可能是，你先用它做最基本的事情，直到你熟悉這些基本操作，再去了解git的其它用法。

git的複雜有一些歷史原因，其中之一是：它過去就很複雜！git的早期使用者是那些為Kernel程式設計的人，他們不得不學習一系列非常難用的指令碼。把絕大多數的精力花費在讓git能用，而不是更易用。所以早期git給大家的印象（確實就）是，你必須很清楚自己在做什麼。當然，在最初的半年或一年裡，事實確實如此。

人們感覺git複雜的另一個原因：git不同以往的SCM。許多人使用CVS十年甚至二十年，但git不是CVS，它們一點也不像。git和CVS的設計理念不同，命令也不同。git從來沒有想過模仿CVS，甚至相反。如果你曾經長時間使用CVS風格的SCM系統，就會感覺git很複雜，並且覺得那些和CVS不同的設計沒有存在的必要。奇怪的修訂編號會讓你分心，你心想：為什麼git的修訂編號不能像CVS的1.3.1那樣累加，而要選擇一個奇怪的40位元組的十六進位制數呢？

但git並不是要故意標新立異。git確實和CVS存在差異，因為人們有不同的知識背景，所以這些差異使人們感覺其中一個比另一個複雜。CVS背景的東西正在漸漸遠去，可能現在很多用過git的人從來沒有用過CVS，他們就會不習慣CVS的使用方式。

你認為沒有git，Linux Kernel能達到目前的開發速度嗎？

Torvalds：呃，沒有git，我認為可以。但那意味著需要有人寫出與git相似的工具：一個像git一樣高效的分散式的SCM。沒錯，我們確實需要像git這樣的東西。

您目前對GitHub有何看法？

Torvalds：毫無疑問，Github是一個非常棒的程式碼託管服務，但我對它仍有一些看法：做為一個開發平臺（提交程式碼，請求更新，跟蹤issue等），GitHub有太多限制。它遠不如Kernel的開發平臺那樣出色。

部分原因是由於Kernel的開發方式——git正是為Kernel開發而生，但另一部分原因是GitHub的介面鼓勵不好的行為。比如，GitHub上的“完成提交”有一些不好的提交資訊。GitHub曾經修復了一些問題，也許現在已經做得很好了，但它永遠不能像Linux Kernel那樣，和git完美結合。

請說一說在 Git 或 GitHub 上您最感興趣的用法？

Torvalds：很高興看到採用git可以很輕鬆的建立一個專案。以前的程式碼託管很難用，有了git和GitHub，建立一些小專案變得非常簡單。專案具體是做什麼並不重要，重要的是你可以做到了。

您最近還有其它專案嗎？其它可以統治未來若干年軟體開發的偉大專案？

Torvalds：目前沒有，如果有的話我會告訴你。