Git 10 週年,Linux 之父談他是怎麼在 10 天內開發完成

【伯樂在線導讀】:十年前的這一周,Linux 內核開發社區正面臨嚴峻的挑戰:他們不能繼續使用 BitKeeper 了(伯樂在線注:原因是當時 Bitkeeper 著作權所有者決定收回授權,內核開發團隊與其協商無果),而又沒有其他的 SCM(Software Configuration Management)可滿足他們的分佈式系統的需求。

Linux 之父 Linus Torvalds 接受了這個挑戰,決定開發一個新的版本控制系統。週末他消失了,新的一周,Git 問世了。今天,Git 已經成為上萬個項目的版本控制系統,並且在工程師中引發了開源熱潮。(TO 注:像 GitHub 就是用 Git 搭建的)

為了慶祝里程碑式的一刻,Linux 基金會邀請了 Linus 來分享 Git 背後的故事,以及他對 Git 在軟體開發中的影響的觀點。

Linus_Torvalds_(cropped)

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 的發展歷程(各個重要里程碑)。點擊 這裡 或下圖,可以欣賞。真心贊!

  • 延伸閱讀

擊敗 Google、微軟開發者平台,GitHub 憑的是什麼?

(本文轉載自合作夥伴《伯樂在線》;未經授權,不得轉載;圖片來源:theducks,CC Licensed)


掌握 2019 年行銷思維:TechOrange 數位行銷論壇

2018 年台灣數位廣告量全年達新台幣 389.66 億, 廣告價格與成效 之間平衡如何拿捏? 找出成效型廣告操作的最精華關鍵,打造數位品牌勝利第一步! 6/19 TechOrange 數位行銷論壇, 6 折早鳥價只到 5/30 >>>> 手刀購買

點關鍵字看更多相關文章: