Git 基礎

本章將介紹幾個最基本的，也是最常用的 Git 命令，以後絕大多數時間裡用到的也就是這幾個命令。讀完本章，你就能初始化一個新的程式碼倉庫，做一些適當配置；開始或停止跟蹤某些檔案；暫存或提交某些更新。我們還會展示如何讓 Git 忽略某些檔案，或是名稱符合特定模式的檔案；如何既快且容易地撤消犯下的小錯誤；如何瀏覽專案的更新歷史，檢視某兩次更新之間的差異；以及如何從遠端倉庫拉資料下來或者推資料上去。

在工作目錄中初始化新倉庫

要對現有的某個專案開始用 Git 管理，只需到此專案所在的目錄，執行：

$ git init

初始化後，在當前目錄下會出現一個名為 .git 的目錄，所有 Git 需要的資料和資源都存放在這個目錄中。不過目前，僅僅是按照既有的結構框架初始化好了裡邊所有的檔案和目錄，但我們還沒有開始跟蹤管理專案中的任何一個檔案。

如果當前目錄下有幾個檔案想要納入版本控制，需要先用 git add 命令告訴 Git 開始對這些檔案進行跟蹤，然後提交：

$ git add *.c 

$ git add README 

$ git commit -m 'initial project version'

現在，你已經得到了一個實際維護著若干檔案的 Git 倉庫

從現有倉庫克隆

如果想對某個開源專案出一份力，可以先把該專案的 Git 倉庫複製一份出來，這就需要用到 git clone 命令。如果你熟悉其他的 VCS 比如 Subversion，你可能已經注意到這裡使用的是 clone 而不是 checkout。這是個非常重要的差別，Git 收取的是專案歷史的所有資料（每一個檔案的每一個版本）

克隆倉庫的命令格式為 git clone [url]。比如，要克隆 Ruby 語言的 Git 程式碼倉庫 Grit，可以用下面的命令：

$ git clone git://github.com/schacon/grit.git

這會在 當前目錄下 建立一個名為 “grit” 的目錄，其中包含一個 .git 的目錄，用於儲存下載下來的所有版本記錄，然後從中取出最新版本 的檔案拷貝。如果進入這個新建的 grit 目錄，你會看到專案中的所有檔案已經在裡邊了，準備好後續的開發和使用。如果希望在克隆的時候，自己定義要新建的專案目錄名稱，可以在上面的命令末尾指定新的名字：

$ git clone git://github.com/schacon/grit.git mygrit

唯一的差別就是，現在新建的目錄成了 mygrit，其他的都和上邊的一樣。

Git 支援許多資料傳輸協議。之前的例子使用的是 git:// 協議，不過你也可以用 http(s):// 或者[email protected]:/path.git 表示的 SSH 傳輸協議。

記錄每次更新到倉庫

現在我們手上已經有了一個真實專案的 Git 倉庫，並從這個倉庫中取出了所有檔案的工作拷貝。接下來，對這些檔案作些修改，在完成了一個階段的目標之後，提交本次更新到倉庫。

工作目錄下面的所有檔案都不外乎這兩種狀態：已跟蹤或未跟蹤。已跟蹤的檔案是指本來就被納入版本控制管理的檔案，在上次快照中有它們的記錄，工作一段時間後，它們的狀態可能是未更新，已修改或者已放入暫存區。而所有其他檔案都屬於未跟蹤檔案。它們既沒有上次更新時的快照，也不在當前的暫存區域。初次克隆某個倉庫時，工作目錄中的所有檔案都屬於已跟蹤檔案，且狀態為 未修改。

在編輯過某些檔案之後，Git 將這些檔案標為已修改。我們逐步把這些修改過的檔案放到暫存區域，直到最後一次性提交所有這些暫存起來的檔案，如此重複。所以使用 Git 時的檔案狀態變化週期如圖 2-1 所示。

檢查當前檔案狀態

要確定 哪些檔案 當前 處於 什麼狀態，可以用 git status 命令。如果在克隆倉庫之後立即執行此命令，會看到類似這樣的輸出：

$git status 

# On branch master nothing to commit (working directory clean)

這說明你 現在的工作目錄 沒有任何檔案在上次提交後更改過。此外，上面的資訊還表明，當前目錄下沒有出現任何處於未跟蹤的新檔案，否則 Git 會在這裡列出來。最後，該命令還顯示了當前所在的分支是 master，這是預設的分支名稱，實際是可以修改的。

現在讓我們用 vim 編輯一個新檔案 README，儲存退出後執行 git status 會看到該檔案出現在未跟蹤檔案列表中：

$ vim README 

$ git status 

# On branch master

# Untracked files: 

# (use "git add <file>..." to include in what will be committed) 

# #	README nothing added to commit but untracked files present (use "git add" to track)

就是在“Untracked files”這行下面。Git 不會自動將之納入跟蹤範圍，除非你明明白白地告訴它“我需要跟蹤該檔案”，因而不用擔心把臨時檔案什麼的也歸入版本管理。不過現在的例子中，我們確實想要跟蹤管理 README 這個檔案。

跟蹤新檔案

使用命令 git add 開始跟蹤一個新檔案。所以，要跟蹤 README 檔案，執行：

$ git add README

此時再執行 git status 命令，會看到 README 檔案已被跟蹤，並處於暫存狀態：

$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# #	new file: README #

只要在 “Changes to be committed” 這行下面的，就說明是已暫存狀態。如果此時提交，那麼該檔案此時此刻的版本將被留存在歷史記錄中。你可能會想起之前我們使用 git init 後就運行了 git add 命令，開始跟蹤當前目錄下的檔案。在 git add 後面可以指明要跟蹤的 檔案 或 目錄 路徑。如果是目錄的話，就說明要遞迴跟蹤該目錄下的所有檔案。

暫存已修改檔案

現在我們修改下之前已跟蹤過的檔案 benchmarks.rb，然後再次執行 status 命令，會看到這樣的狀態報告：

$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# #	new file: README 

# # Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 

# #	modified: benchmarks.rb #

檔案 benchmarks.rb 出現在 “Changed but not updated” 這行下面，說明已跟蹤檔案的內容發生了變化，但還沒有放到 暫存區。要暫存這次更新，需要執行 git add 命令（這是個多功能命令，根據目標檔案的狀態不同，此命令的效果也不同：可以用它開始跟蹤 新檔案，或者把 已跟蹤的檔案放到暫存區，還能用於合併時把 有衝突的檔案標記為已解決狀態等）。現在讓我們執行 git add 將 benchmarks.rb 放到暫存區，然後再看看 git status 的輸出：

$ git add benchmarks.rb 

$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# #	new file: README 

#	modified: benchmarks.rb #

現在兩個檔案都已暫存，下次提交時就會一併記錄到倉庫。假設此時，你想要在 benchmarks.rb 裡再加條註釋，重新編輯存檔後，準備好提交。不過且慢，再執行 git status 看看：

$ vim benchmarks.rb 

$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# #	new file: README 

#	modified: benchmarks.rb 

# # Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 

# #	modified: benchmarks.rb #

怎麼回事？benchmarks.rb 檔案出現了兩次！一次算未暫存，一次算已暫存，這怎麼可能呢？好吧，實際上 Git 只不過暫存了你執行 git add 命令時的版本，如果現在提交，那麼提交的是添加註釋前的版本，而非當前工作目錄中的版本。所以，運行了 git add 之後又作了修訂的檔案，需要重新執行 git add 把最新版本重新暫存起來：

$ git add benchmarks.rb 

$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

#

#	new file: README 

#	modified: benchmarks.rb 

#

忽略某些檔案

一般我們總會有些檔案無需納入 Git 的管理，也不希望它們總出現在未跟蹤檔案列表。通常都是些自動生成的檔案，比如日誌檔案，或者編譯過程中建立的臨時檔案等。我們可以在當前工程下建立一個名為 .gitignore 的檔案，列出要忽略的檔案模式。來看一個實際的例子：

$ cat .gitignore 

*.[oa] 

*~

第一行告訴 Git 忽略所有以 .o 或 .a 結尾的檔案。一般這類物件檔案和存檔檔案都是編譯過程中出現的，我們用不著跟蹤它們的版本。第二行告訴 Git 忽略所有以波浪符（~）結尾的檔案，許多文字編輯軟體（比如 Emacs）都用這樣的檔名儲存副本。此外，你可能還需要忽略 log，tmp 或者 pid 目錄，以及自動生成的文件等等。要養成一開始就設定好 .gitignore 檔案的習慣，以免將來誤提交這類無用的檔案。

檔案 .gitignore 的格式規範如下：

• 所有空行或者以註釋符號 ＃ 開頭的行都會被 Git 忽略。
• 可以使用標準的 glob 模式匹配。 * 匹配模式最後跟反斜槓（/）說明要忽略的是目錄。 * 要忽略指定模式以外的檔案或目錄，可以在模式前加上驚歎號（!）取反。

所謂的 glob 模式是指 shell 所使用的簡化了的正則表示式。星號（*）匹配零個或多個任意字元；[abc] 匹配任何一個列在方括號中的字元（這個例子要麼匹配一個 a，要麼匹配一個 b，要麼匹配一個 c）；問號（?）只匹配一個任意字元；如果在方括號中使用短劃線分隔兩個字元，表示所有在這兩個字元範圍內的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的數字）。

我們再看一個 .gitignore 檔案的例子：

# 此為註釋 – 將被 Git 忽略 

*.a # 忽略所有 .a 結尾的檔案 

!lib.a # 但 lib.a 除外 

/TODO # 僅僅忽略專案根目錄下的 TODO 檔案，不包括 subdir/TODO 

build/ # 忽略 build/ 目錄下的所有檔案 

doc/*.txt # 會忽略 doc/notes.txt 但不包括 doc/server/arch.txt