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權威指南》，您可以訪問【作者部落格】【作者微博】【本書官網】【互動網】【噹噹網】，感謝關注！