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：目前沒有，若是有的話我會告訴你。