十年前的這一周，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：目前沒有，如果有的話我會告訴你。
本文位址：http://www.oschina.net/translate/10-years-of-git-an-interview-with-git-creator-linus-torvalds
原文位址：http://www.linux.com/news/featured-blogs/185-jennifer-cloer/821541-10-years-of-git-an-interview-with-git-creator-linus-torvalds
refer:
http://geek.csdn.net/news/detail/30067