Git權威指南

 
Git權威指南(作者:蔣鑫)

 

《Git權威指南》前言

版本控制是管理數據變更的藝術,無論數據變更是來自同一個人,還是來自不同的人(一個團隊)。版本控制系統不但要忠實地記錄數據的每一次變更,還要能夠幫助還原任何一次歷史變更,以及實現團隊的協同工作等。Git 就是版本控制系統中的佼佼者。

我對版本控制系統的興趣源自於我的個人知識管理實踐,其核心就是撰寫可維護的文檔,並保存於版本控制系統中。可維護文檔的格式可以是 DocBook、FreeMind、reStructuredText 等。我甚至還對 FreeMind 加以改造以便讓其文檔格式更適合於版本控制系統,這就是我的第一個開源實踐:託管於 SourceForge 上的 FreeMind-MMX 項目。文檔書寫格式的問題解決之後,就是文檔的存儲問題了。通過版本控制系統,很自然地就可以實現對文檔歷史版本的保存,但是如何避免因爲版本控制系統癱 瘓而導致數據丟失呢?Git 用其嶄新的分佈式的版本控制設計提供了最好的解決方案。使用 Git,我的知識庫不再只有唯一的版本庫與之對應,而是可以通過克隆操作分發到不同的磁盤或主機上,克隆的版本庫之間通過推送(PUSH)和拉回 (PULL)等操作進行同步,數據安全得到了極大的提升。在版本控制系統的忠實呵護下,我的知識庫中關於Git的 FreeMind 腦圖在日積月累中變得越來越翔實,越來越清晰,最終成爲本書的雛形。

版本控制能決定項目的成敗,甚至是公司的生死,此言不虛。我在推廣開源項目管理工具和爲企業提供諮詢服務的過程中看到,有很多團隊因爲版本控制系統 管理的混亂導致項目延期、修正的 Bug 重現、客戶的問題不能在代碼中定位……無論他們使用的是什麼版本控制系統(開源的或是商業的)都是如此。這是因爲傳統的集中式版本控制系統不能有效地管理 分支和進行分支間合併。集中管理的版本庫只有唯一的分支命名空間,需要專人管理,從而造成分支創建的不自由;分支間的合併要麼因爲缺乏追蹤導致重複合併、 引發嚴重衝突,要麼因爲版本控制系統本身蹩腳的設計導致分支合併時效率低下和陷阱重重。Git憑藉其靈活的設計讓項目擺脫分支管理的夢魘。

我的公司也經歷過代碼管理的生死考驗。因爲公司的開發模式主要是基於開源軟件的二次開發,所以最早在使用SVN(Subversion)做版本控制 時,很自然地使用了SVN賣主分支模型來管理代碼。隨着增加和修改的代碼越來越多,我們開發的軟件與開源軟件上游的偏離也越來越遠,當上遊有新版本發佈 時,最早可能只用幾個小時就可以將改動遷移過去,但是如果對上游的改動多達幾十甚至上百處時,遷移的過程就會異常痛苦,基本上和重新做一遍差不多。那時似 乎只有一種選擇:不再與上游合併,不再追蹤上游的改動,而這與公司的價值觀“發動全球智慧爲客戶創造價值”相違背。迷茫之中,分佈式版本控制系統飄然而 至,原來版本控制還可以這麼做。

我最先嚐試的分佈式版本控制系統是 Hg(Mercurial),當發現Hg和 MQ(Hg 的一個插件)這一對寶貝兒的時候,我如獲至寶。逐漸地,公司的版本庫都遷移到了Hg上。但隨着新的開發人員的加入,問題又出現了,一個人使用Hg和MQ很 好,但多個人使用時則會出現難以協同的問題。於是我們大膽地採用了 Git,並在實踐中結合 Topgit 等工具進行代碼的管理。再一次,也許是最後一次,我們的代碼庫遷移到了 Git。

最早認識分佈式版本控制,源自於我們看到了衆多開源項目的版本控制系統大遷移,這場遷移還在進行中。

  • MoinMoin 是我們關注的一個開源的維基軟件,2006 年,它的代碼庫從SVN遷移到了Hg。
  • Mailman 同樣是我們關注的一個開源郵件列表軟件。2007 年,它的代碼庫從SVN遷移到了 Bazaar。
  • Linux 採用Git作爲版本控制系統(一點都不奇怪,因爲Git就是 Linus Torvalds 開發的)。
  • Android 是目前最爲流行的開源項目之一,因爲潛在市場巨大,已經吸引了越來越多的開發者進入這個市場,而Android就是用Git維護的。

當開源軟件紛紛倒向分佈式版本控制系統大旗(尤其是Git)的時候,很多商業公司也在行動了,尤其是涉及異地團隊協同和Android核心代碼定製 開發的公司。對於那些因保守而不敢向Git靠攏的公司,Git也可以派上用場,因爲Git可以與現在大多數公司部署的SVN很好地協同,即公司的服務器是 SVN,開發者的客戶端則使用 Git。相信隨着Git的普及,以及公司在代碼管理觀念上的改進,會有更多的公司擁抱 Git。

本書的組織

本書共分爲9篇,前8篇是正文,一共41章,第9篇是附錄。

第1篇講解了Git的相關概念,以及安裝和配置的方法,共3章。第1章介紹了版本控制的歷史。第2章用十幾個小例子介紹了Git的一些閃亮特性,期 待這些特性能夠讓你愛上Git。第3章則介紹了Git在三種主要操作系統平臺上的安裝和使用。在本書的寫作過程中,我70%的時間使用的是Debian Linux操作系統,Linux用戶可以毫無障礙地完成本書列舉的所有實踐操作。在2010年年底,當得知有出版社願意出版這本書後,我向妻子阿巧預支了 未來的部分稿費購買了我的第一臺 MacBook Pro,於是本書就有了較爲翔實的如何在Mac OS X下安裝和使用Git的內容,以及在本書第22章中介紹的關於Topgit在Mac OS X上的部署和改進相關的內容。在本書的編輯和校對過程中因爲要使用 Word 格式的文稿,所以本書後期的很多工作是在運行於 VirtualBox 下的 Windows 虛擬機中完成的,即使是使用運行於資源受限的虛擬機中的 Cygwin,Git 依然完美地完成了工作。

第2篇和第3篇詳細講解了Git的使用方法,是本書的基礎和核心,大約佔據了全書40%的篇幅。這兩篇的內容架構方式是我在進行SVN培訓時就已經 形成的習慣,即以“獨奏”指代一個人的版本控制所要講述的知識點,以“和聲”指代團隊版本控制涉及的話題。在第2篇“Git獨奏”中,本書將Git的設計 原理穿插在各章之中講解,因爲唯有了解真相(Git原理),纔有可能自由(掌握Git)。在第3篇“Git和聲”中,本書講解了團隊版本控制必須掌握的裏 程碑和分支等概念,以及如何解決合併中遇到的衝突。

第4篇細緻地講解了Git在實際工作中的使用模式。除了傳統的集中式和分佈式使用模式之外,第22章還介紹了 Topgit 在定製開發中的應用,這也是我公司在使用Git時採用的最主要的模式。這一章還講解了我對 Topgit 所做的部分改進,相關的具體介紹最早出現在我公司的博客上①。第23~25章介紹了多版本庫協同的不同方法,其中第25章介紹的一個獨闢蹊徑的解決方案是 由 Android 項目引入的名爲repo的工具實現的,我對其進行改造後可以讓這個工具脫離Gerrit代碼審覈服務器,直接操作Git服務器。第26章介紹了git- svn這一工具,該工具不但可以實現從SVN版本庫到Git版本庫的遷移,還可以實現以Git作爲客戶端向SVN提交。

第5篇介紹了Git服務器的架設。本篇是全書最早開始撰寫的部分,這是因爲我給客戶做的Git培訓講義的相關內容不夠詳細,於是應客戶要求針對 Gitolite等服務器的架設撰寫了詳細的管理員手冊,即本書的第30章。第32章介紹了Android項目在Git管理上的又一大創造,即 Gerrit,它實現了一個獨特的集中式Git版本庫管理模型。

第6篇講解了Git版本庫的遷移。其中第34章詳細介紹了從CVS版本庫到Git版本庫的遷移,其遷移過程也可以作爲從CVS到SVN遷移的借鑑。 本篇還介紹了從SVN和Hg版本庫到Git的遷移。對於其他類型的版本庫,介紹了一個通用的需要編程來實現的方法。在本篇的最後還介紹了一個Git版本庫 整理的利器,可以理解爲一個Git庫轉換爲另外一個Git庫的方法。

第7篇是關於Git的其他應用,其主要內容介紹了我在etckeeper啓發下開發的一款備份工具 Gistore,該工具可以運行於Linux和Mac OS X下。

第8篇是Git雜談。其中第40章的內容可供跨平臺的項目組借鑑。第41章介紹了一些在前面沒有涉及的Git的相關功能和特性。

第9篇是附錄。首先介紹了完整的Git命令索引,然後分別介紹了CVS、SVN、Hg與Git之間的比較和命令對照,對於有其他版本控制系統使用經驗的用戶而言,這一部分內容頗具參考價值。

適用讀者

本書適合所有翻開它的人,因爲我知道這本書在書店裏一定是放在計算機圖書專櫃。本書尤其適合以下幾類讀者閱讀。

1.被數據同步困擾的“電腦人”

困擾“電腦人”的一個常見問題是,有太多的數據需要長久保存,有太多的電腦設備需要數據同步。可能有的人會說:“像Dropbox一樣的網盤可以幫 助我呀”。是的,雲存儲就是在技術逐漸成熟之後應運而生的產品,但是依然解決不了如下幾個問題:多個設備上同時修改造成的衝突;冗餘數據傳輸造成的帶寬瓶 頸;沒有實現真正的、完全的歷史變更數據備份。具體請參見本書第7篇第39章的內容。

Git可以在數據同步方面做得更好,甚至只需藉助小小的U盤就可以實現多臺電腦的數據同步,並且支持自動的衝突解決。只要閱讀本書第1篇和第2篇,就能輕易掌握相關的操作,實現數據的版本控制和同步。

2.學習計算機課程的學生

我非常後悔沒有在學習編程的第一天就開始使用版本控制,在學校時寫的很多小程序和函數庫都丟失了。直到使用了CVS和SVN對個人數據進行版本控制之後,纔開始把每一天的變更歷史都保留了下來。Git在這方面可以比CVS和SVN等做得更好。

在閱讀完本書的前3篇掌握了Git的基礎知識之後,可以閱讀第5篇第33章的內容,通過 Github 或類似的服務提供商建立自己的版本庫託管,爲自己的數據找一個安全的家。

3. 程序員

使用Git會讓程序員有更多的時間休息,因爲可以更快地完成工作。分佈式版本控制讓每一個程序員都能在本地擁有一個完整的版本庫,所以幾乎所有操作都能夠脫離網絡執行而不受帶寬的限制。加之使用了智能協議,版本庫間的同步不但減少了數據傳輸量,還能顯示完成進度。

Git幫助程序員打開了進入開源世界的大門,進而開闊視野,提升水平,增加擇業的砝碼。看看使用Git作爲版本控制的開源軟件吧:Linux kernel、Android、Debian、Fedora、GNOME、KDevelop、jQuery、Prototype、PostgreSQL、 Ruby on Rails……不勝枚舉。還有,不要忘了所有的SVN版本庫都可以通過Git方式更好地訪問。

作爲一個程序員,必須具備團隊協同能力,本書第3篇應該作爲學習的重點。

4.Android程序員

如果你是谷歌Android項目的參與者,尤其是驅動開發和核心開發的參與者,必然會接觸Git、repo和Gerrit。對於只是偶爾參考一下 Android核心代碼的Android應用開發人員而言,也需要對repo有深入的理解,這樣才不至於每次爲同步代碼而耗費一天的時間。

repo是Android爲了解決Git多版本庫管理問題而設計的工具,在本書第4篇第25章有詳細介紹。

Gerrit是谷歌爲了避免因分佈式開發造成項目分裂而開發的工具,打造了Android獨具一格的集中式管理模式,在本書第5篇第32章有詳細介紹。

即使是非Android 項目,也可以使用這兩款工具爲自己的項目服務。我還爲repo寫了幾個新的子命令以實現脫離Gerrit提交,讓repo擁有更廣泛的應用領域。

5.定製開發程序員

當一個公司的軟件產品需要針對不同的用戶進行定製開發時,就需要在一個版本庫中建立大量的特性分支,使用SVN的分支管理遠不如使用Git的分支管 理那麼自然和方便。還有一個應用領域就是對第三方代碼進行維護。當使用SVN進行版本控制時,最自然的選擇是賣主分支,但隨着定製開發的逐漸深入,與上游 的偏離也會越大,於是與上游代碼的合併也將越來越令人痛苦。

第4篇第22章介紹Topgit這一殺手級的工具,這是這個領域最佳的解決方案。

6.SVN用戶

商業軟件的研發團隊因爲需要精細的代碼授權,所以不會輕易更換現有的SVN版本控制系統,這種情況下Git依然大有作爲。無論是出差在外,或是在家 辦公,或是開發團隊分處異地,都會遇到SVN版本控制服務器無法訪問或速度較慢的情況。這時git-svn這一工具會將Git和SVN完美地結合在一起, 既嚴格遵守SVN的授權規定,又可以自如地進行本地提交,當能夠連接到SVN服務器時,可以在悠閒地喝着綠茶的同時,等待一次性批量提交的完成。

我有幾個項目(pySvnManager、Freemind-MMX)託管在 SourceForge 的SVN服務器上,現在都是先通過 git-svn 將其轉化爲本地的Git庫,然後再使用的。以這樣的方式訪問歷史數據、比較代碼或提交代碼,再也不會因爲網速太慢而望眼欲穿了。

本書第4篇第26章詳細介紹了Git和SVN的互操作。

7. 管理員

Git在很大程度上減輕了管理員的負擔:分支的創建和刪除不再需要管理員統一管理,因爲作爲分佈式版本控制系統,每一個克隆就是一個分支,每一個克 隆都擁有獨立的分支命名空間;管理員也不再需要爲版本庫的備份操心,因爲每一個項目成員都擁有一個備份;管理員也不必擔心有人在服務器上篡改版本庫,因爲 Git版本庫的每一個對象(提交和文件等)都使用SHA1哈希值進行完整性校驗,任何對歷史數據的篡改都會因爲對後續提交產生的連鎖反應而原形畢露。

本書第7篇第37章介紹了一款我開發的基於Git的備份工具,它使得 Linux 系統的數據備份易如反掌。本書第5篇介紹的Git服務器搭建,以及第6篇介紹的版本庫遷移方面的知識會爲版本控制管理員的日常維護工作提供指引。

8. 開發經理

作爲開發經理,你一定要對代碼分支有深刻的理解,不知本書第18章中的“代碼管理之殤”是否能引起你的共鳴。爲了能在各種情況下恰當地管理開發團 隊,第4篇“Git協同模型”是項目經理應該關注的重點。你的團隊是否存在着跨平臺開發,或者潛在着跨平臺開發的可能?本書第8篇第40章也是開發經理應 當關注的內容。

排版約定

本書使用的排版格式約定如下:

1. 命令輸出及示例代碼

執行一條Git命令及其輸出的示例如下:
$ git –version
git version 1.7.4

2. 提示符($)

命令前面的 $ 符號代表命令提示符。

3. 等寬字體(Constant width)

用於標示屏幕輸出的字符 、示例代碼,以及正文中出現的命令、參數、文件名和函數名等。

4. 等寬粗體(Constant width bold)

用於表示由用戶手工輸入的內容。

5. 佔位符()

用尖括號擴起來的內容,表示命令中或代碼中的佔位符,讀者應當用實際值將其替換。

在線資源

官方網站:http://www.ossxp.com/doc/gotgit/

在本書的官方網站上,大家可以瞭解到與本書相關的最新信息,查看本書的勘誤,以及下載與本書相關的資源。官網是以Git方式維護的,人人都可以參與其中。

新浪微博:http://weibo.com/GotGit

歡迎大家通過新浪微博與作者交流,也歡迎大家通過新浪微博將你們的寶貴意見和建議反饋給作者。

致謝

感謝 Linus Torvalds、Junio C Hamano 和Git項目的所有貢獻者,是他們帶給我們嶄新的版本控制體驗。

本書能夠出版要感謝機械工業出版社華章公司,華章公司對中文原創計算機圖書的信任讓中國的每一個計算機從業者都有可能圓自己出書的夢想。作爲一個新 人,拿着一個新的選題,遇到同樣充滿激情的編輯,我無疑是幸運的。這個充滿激情的編輯,就是華章公司的楊福川編輯。甚至沒有向我索要樣章,在看過目錄之後 就“冒險”和我簽約,他的激情讓我不敢懈怠。同樣要感謝王曉菲編輯,她的耐心和細緻讓我吃驚,也正是因爲她的工作本書的行文才能更加流暢,本書也才能夠更 快問世。還有張少波編輯,感謝她在接到我的電話後幫我分析選題並推薦給楊福川編輯。

本書的部分內容是由我的Git培訓講義擴展而來的,在此感謝朝歌數碼的蔣宗貴,是他的鼓勵和鞭策讓我完善了本書中的與服務器架設的相關章節。還要感謝王彥寧,正是通過她的團隊我才認識了 Android,纔有了本書關於 repo 和 Gerrit 的相關章節。

感謝羣英匯的同事們,尤其要感謝王勝,正是因爲我們在使用 Topgit 0.7 版本時遇到了嚴重的衝突,才使我下定決心研究 Git。

感謝上海愛立信研發中心的高級技術專家蔡煜,他對全書尤其是git-svn和Gitolite相關章節做了重點評審,他的意見和建議修正了本書的很多不當之處。因爲時間的關係,他的一些非常好的觀點沒有機會在這一版中體現,爭取在改版時彌補遺憾。

中國科學院軟件研究所的張先軼、比蒙科技的宋伯潤和楊致偉、摩博科技的熊軍、共致開源的秦紅勝,以及王勝等人爲本書的技術審校提供了幫助,感謝他們 的寶貴意見和建議。來自中國臺灣的PyLabs 團隊糾正了本書在對Hg的認識上的偏頗,讓本書附錄中的相關內容更加準確和客觀,在此向他們表示感謝。

因爲寫書虧欠家人很多,直到最近才發現女兒小雪是多麼希望擁有一臺兒童自行車。感謝妻子阿巧對我的耐心和爲家庭的付出。感謝岳父、岳母這幾年來對小 雪和我們整個家庭的照顧,讓我沒有後顧之憂。還要感謝我的父母和妹妹,他們對我事業的支持和鼓勵是我前進的動力。在我寫作本書的同時,老爸正在富春江畔代 表哈爾濱電機廠監督發電機組的製造,而且也在寫一本監造手冊方面的書,抱歉老爸,我先完成了。 :)

蔣鑫(http://www.ossxp.com/
2011年4月

--------------------------------------
關於《Git權威指南》,您可以訪問【作者博客 】【作者微博 】【本書官網 】【互動網 】【噹噹網 】,感謝關注!

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章