git的詳細用法和基礎教程
Git 是當前最流行的版本控制程式之一，文字包含了 Git 的一些基本用法 建立 git 倉庫 初始化 git 倉庫
mkdir project # 建立專案目錄
cd project # 進入到專案目錄
git init # 初始化 git 倉庫。此命令會在當前目錄新建一個 .git 目錄，用於儲存 git 倉庫的相關資訊
初始化提交
touch README
git add . # 將當前目錄新增到 git 倉庫中， 使用 git add -A 則是新增所有改動的文件
git commit -m "Initial commit"
git remote add origin git @
修補提交（修補最近一次的提交而不建立新的提交）
git commit --amend -m "commit message."
提交衝突時可以合併後再推送
git pull # 獲取遠端版本庫提交與本地提交進行合併
git push # 提交
使用別人的倉庫
git clone http: //path /to /git.git # clone 的內容會放在當前目錄下的新目錄
將程式碼從本地回傳到倉庫
git push -u origin master
使用 git status 檢視檔案狀態
git status
檢視提交日誌
git log # 檢視提交資訊
git log --pretty=oneline # 以整潔的單行形式顯示提交資訊
Git 分支
git branch # 檢視分支
git branch 6.x- 1.x # 新增分支 6.x-1.x
git branch checkout master # 切換到主分支
git branch -d 6.x- 1.x # 刪除分支 6.x-1.x
git push origin :branchname # 刪除遠端分支
Git 標籤
git tag # 檢視分支
git tag 6.x- 1.0 # 新增標籤 6.x-1.0
git show 6.x- 1.0 # 檢視標籤 6.x-1.0 的資訊
git tag -a 6.x- 1.0 965e066 # 為之前提交的資訊記錄 965e066 加上標籤
git push --tags # 提交時帶上標籤資訊
git push origin : /refs /tags /tagname # 刪除遠端標籤
從 git 倉庫中匯出專案
git archive --format tar --output /path /to /file.tar master # 將 master 以 tar 格式打包到指定檔案
使用 Git 的一些基本守則： 當要commit/提交patch時：
· 使用 git diff --check 檢查行尾有沒有多餘的空白
· 每個 commit 只改一件事情。如果一個文件有多個變更，使用 git add --patch 只選擇文件中的部分變更進入 stage
· 寫清楚 commit message
Git詳解之一 Git起步
|
您的評價: |
起步
本章介紹開始使用 Git 前的相關知識。我們會先了解一些版本控制工具的歷史背景，然後試著讓 Git 在你的系統上跑起來，直到最後配置好，可以正常開始開發工作。讀完本章，你就會明白為什麼 Git 會如此流行，為什麼你應該立即開始使用它。
1.1 關於版本控制
什麼是版本控制？我真的需要嗎？版本控制是一種記錄若干檔案內容變化，以便將來查閱特定版本修訂情況的系統。在本書所展示的例子中，我們僅對儲存著軟體原始碼的文字檔案作版本控制管理，但實際上，你可以對任何型別的檔案進行版本控制。
如果你是點陣圖形或網頁設計師，可能會需要儲存某一幅圖片或頁面佈局檔案的所有修訂版本（這或許是你非常渴望擁有的功能）。採用版本控制系統 （VCS）是個明智的選擇。有了它你就可以將某個檔案回溯到之前的狀態，甚至將整個專案都回退到過去某個時間點的狀態。你可以比較檔案的變化細節，查出最 後是誰修改了哪個地方，從而導致出現怪異問題，又是誰在何時報告了某個功能缺陷等等。使用版本控制系統通常還意味著，就算你亂來一氣把整個專案中的檔案改 的改刪的刪，你也照樣可以輕鬆恢復到原先的樣子。但額外增加的工作量卻微乎其微。
本地版本控制系統
許多人習慣用複製整個專案目錄的方式來儲存不同的版本，或許還會改名加上備份時間以示區別。這麼做唯一的好處就是簡單。不過壞處也不少：有時候會混淆所在的工作目錄，一旦弄錯檔案丟了資料就沒法撤銷恢復。
為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是採用某種簡單的資料庫來記錄檔案的歷次更新差異（見圖 1-1）。
圖 1-1. 本地版本控制系統
其中最流行的一種叫做 rcs，現今許多計算機系統上都還看得到它的蹤影。甚至在流行的 Mac OS X 系統上安裝了開發者工具包之後，也可以使用 rcs 命令。它的工作原理基本上就是儲存並管理檔案補丁（patch）。檔案補丁是一種特定格式的文字檔案，記錄著對應檔案修訂前後的內容變化。所以，根據每次 修訂後的補丁，rcs 可以通過不斷打補丁，計算出各個版本的檔案內容。
集中化的版本控制系統
接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？於是，集中化的版本控制系統（ Centralized Version Control Systems，簡稱 CVCS ）應運而生。這類系統，諸如 CVS，Subversion 以及 Perforce 等，都有一個單一的集中管理的伺服器，儲存所有檔案的修訂版本，而協同工作的人們都通過客戶端連到這臺伺服器，取出最新的檔案或者提交更新。多年以來，這 已成為版本控制系統的標準做法（見圖 1-2）。
圖 1-2. 集中化的版本控制系統
這種做法帶來了許多好處，特別是相較於老式的本地 VCS 來說。現在，每個人都可以在一定程度上看到專案中的其他人正在做些什麼。而管理員也可以輕鬆掌控每個開發者的許可權，並且管理一個 CVCS 要遠比在各個客戶端上維護本地資料庫來得輕鬆容易。
事分兩面，有好有壞。這麼做最顯而易見的缺點是中央伺服器的單點故障。如果宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。要 是中央伺服器的磁碟發生故障，碰巧沒做備份，或者備份不夠及時，就還是會有丟失資料的風險。最壞的情況是徹底丟失整個專案的所有歷史更改記錄，而被客戶端 提取出來的某些快照資料除外，但這樣的話依然是個問題，你不能保證所有的資料都已經有人事先完整提取出來過。本地版本控制系統也存在類似問題，只要整個項 目的歷史記錄被儲存在單一位置，就有丟失所有歷史更新記錄的風險。
分散式版本控制系統
於是分散式版本控制系統（ Distributed Version Control System，簡稱 DVCS ）面世了。在這類系統中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客戶端並不只提取最新版本的檔案快照，而是把原始的程式碼倉庫完整地映象下來。這麼一來，任何一處協同工作用的伺服器發生故障，事後都可以用任何一個鏡 像出來的本地倉庫恢復。因為每一次的提取操作，實際上都是一次對程式碼倉庫的完整備份（見圖 1-3）。
圖 1-3. 分散式版本控制系統
更進一步，許多這類系統都可以指定和若干不同的遠端程式碼倉庫進行互動。籍此，你就可以在同一個專案中，分別和不同工作小組的人相互協作。你可以根據需要設定不同的協作流程，比如層次模型式的工作流，而這在以前的集中式系統中是無法實現的。
1.2 Git 簡史
同生活中的許多偉大事件一樣，Git 誕生於一個極富紛爭大舉創新的年代。Linux 核心開源專案有著為數眾廣的參與者。絕大多數的 Linux 核心維護工作都花在了提交補丁和儲存歸檔的繁瑣事務上（1991－2002年間）。到 2002 年，整個專案組開始啟用分散式版本控制系統 BitKeeper 來管理和維護程式碼。
到了 2005 年，開發 BitKeeper 的商業公司同 Linux 核心開源社群的合作關係結束，他們收回了免費使用 BitKeeper 的權力。這就迫使 Linux 開源社群（特別是 Linux 的締造者 Linus Torvalds ）不得不吸取教訓，只有開發一套屬於自己的版本控制系統才不至於重蹈覆轍。他們對新的系統制訂了若干目標：
* 速度 * 簡單的設計 * 對非線性開發模式的強力支援（允許上千個並行開發的分支） * 完全分散式 * 有能力高效管理類似 Linux 核心一樣的超大規模專案（速度和資料量）
自誕生於 2005 年以來，Git 日臻成熟完善，在高度易用的同時，仍然保留著初期設定的目標。它的速度飛快，極其適合管理大專案，它還有著令人難以置信的非線性分支管理系統（見第三章），可以應付各種複雜的專案開發需求。
1.3 Git 基礎
那麼，簡單地說，Git 究竟是怎樣的一個系統呢？請注意，接下來的內容非常重要，若是理解了 Git 的思想和基本工作原理，用起來就會知其所以然，遊刃有餘。在開始學習 Git 的時候，請不要嘗試把各種概念和其他版本控制系統（諸如 Subversion 和 Perforce 等）相比擬，否則容易混淆每個操作的實際意義。Git 在儲存和處理各種資訊的時候，雖然操作起來的命令形式非常相近，但它與其他版本控制系統的做法頗為不同。理解這些差異將有助於你準確地使用 Git 提供的各種工具。
直接記錄快照，而非差異比較
Git 和其他版本控制系統的主要差別在於，Git 只關心檔案資料的整體是否發生變化，而大多數其他系統則只關心檔案內容的具體差異。這類系統 （CVS，Subversion，Perforce，Bazaar 等等）每次記錄有哪些檔案作了更新，以及都更新了哪些行的什麼內容，請看圖 1-4。
圖 1-4. 其他系統在每個版本中記錄著各個檔案的具體差異
Git 並不儲存這些前後變化的差異資料。實際上，Git 更像是把變化的檔案作快照後，記錄在一個微型的檔案系統中。每次提交更新時，它會縱覽一遍所有檔案的指紋資訊並對檔案作一快照，然後儲存一個指向這次快照 的索引。為提高效能，若檔案沒有變化，Git 不會再次儲存，而只對上次儲存的快照作一連結。Git 的工作方式就像圖 1-5 所示。
圖 1-5. Git 儲存每次更新時的檔案快照
這是 Git 同其他系統的重要區別。它完全顛覆了傳統版本控制的套路，並對各個環節的實現方式作了新的設計。Git 更像是個小型的檔案系統，但它同時還提供了許多以此為基礎的超強工具，而不只是一個簡單的 VCS。稍後在第三章討論 Git 分支管理的時候，我們會再看看這樣的設計究竟會帶來哪些好處。
近乎所有操作都是本地執行
在 Git 中的絕大多數操作都只需要訪問本地檔案和資源，不用連網。但如果用 CVCS 的話，差不多所有操作都需要連線網路。因為 Git 在本地磁碟上就儲存著所有當前專案的歷史更新，所以處理起來速度飛快。
舉個例子，如果要瀏覽專案的歷史更新摘要，Git 不用跑到外面的伺服器上去取資料回來，而直接從本地資料庫讀取後展示給你看。所以任何時候你都可以馬上翻閱，無需等待。如果想要看當前版本的檔案和一個月 前的版本之間有何差異，Git 會取出一個月前的快照和當前檔案作一次差異運算，而不用請求遠端伺服器來做這件事，或是把老版本的檔案拉到本地來作比較。
用 CVCS 的話，沒有網路或者斷開 VPN 你就無法做任何事情。但用 Git 的話，就算你在飛機或者火車上，都可以非常愉快地頻繁提交更新，等到了有網路的時候再上傳到遠端倉庫。同樣，在回家的路上，不用連線 VPN 你也可以繼續工作。換作其他版本控制系統，這麼做幾乎不可能，抑或非常麻煩。比如 Perforce，如果不連到伺服器，幾乎什麼都做不了（譯註：預設無法發出命令p4 edit file 開始編輯檔案，因為 Perforce 需要聯網通知系統宣告該檔案正在被誰修訂。但實際上手工修改檔案許可權可以繞過這個限制，只是完成後還是無法提交更新。）；如果是 Subversion 或 CVS，雖然可以編輯檔案，但無法提交更新，因為資料庫在網路上。看上去好像這些都不是什麼大問題，但實際體驗過之後，你就會驚喜地發現，這其實是會帶來 很大不同的。
時刻保持資料完整性
在儲存到 Git 之前，所有資料都要進行內容的校驗和（checksum）計算，並將此結果作為資料的唯一標識和索引。換句話說，不可能在你修改了檔案或目錄之後，Git 一無所知。這項特性作為 Git 的設計哲學，建在整體架構的最底層。所以如果檔案在傳輸時變得不完整，或者磁碟損壞導致檔案資料缺失，Git 都能立即察覺。
Git 使用 SHA-1 演算法計算資料的校驗和，通過對檔案的內容或目錄的結構計算出一個 SHA-1 雜湊值，作為指紋字串。該字串由 40 個十六進位制字元（0-9 及 a-f）組成，看起來就像是：
24b9da6552252987aa493b52f8696cd6d3b00373
Git 的工作完全依賴於這類指紋字串，所以你會經常看到這樣的雜湊值。實際上，所有儲存在 Git 資料庫中的東西都是用此雜湊值來作索引的，而不是靠檔名。
多數操作僅新增資料
常用的 Git 操作大多僅僅是把資料新增到資料庫。因為任何一種不可逆的操作，比如刪除資料，都會使回退或重現歷史版本變得困難重重。在別的 VCS 中，若還未提交更新，就有可能丟失或者混淆一些修改的內容，但在 Git 裡，一旦提交快照之後就完全不用擔心丟失資料，特別是養成定期推送到其他倉庫的習慣的話。
這種高可靠性令我們的開發工作安心不少，儘管去做各種試驗性的嘗試好了，再怎樣也不會弄丟資料。至於 Git 內部究竟是如何儲存和恢復資料的，我們會在第九章討論 Git 內部原理時再作詳述。
檔案的三種狀態
好，現在請注意，接下來要講的概念非常重要。對於任何一個檔案，在 Git 內都只有三種狀態：已提交（committed），已修改（modified）和已暫存（staged）。已提交表示該檔案已經被安全地儲存在本地資料庫 中了；已修改表示修改了某個檔案，但還沒有提交儲存；已暫存表示把已修改的檔案放在下次提交時要儲存的清單中。
由此我們看到 Git 管理專案時，檔案流轉的三個工作區域：Git 的工作目錄，暫存區域，以及本地倉庫。
圖 1-6. 工作目錄，暫存區域，以及本地倉庫
每個專案都有一個 Git 目錄（譯註：如果 git clone 出來的話，就是其中 .git 的目錄；如果git clone --bare 的話，新建的目錄本身就是 Git 目錄。），它是 Git 用來儲存元資料和物件資料庫的地方。該目錄非常重要，每次克隆映象倉庫的時候，實際拷貝的就是這個目錄裡面的資料。
從專案中取出某個版本的所有檔案和目錄，用以開始後續工作的叫做工作目錄。這些檔案實際上都是從 Git 目錄中的壓縮物件資料庫中提取出來的，接下來就可以在工作目錄中對這些檔案進行編輯。
所謂的暫存區域只不過是個簡單的檔案，一般都放在 Git 目錄中。有時候人們會把這個檔案叫做索引檔案，不過標準說法還是叫暫存區域。
基本的 Git 工作流程如下：
1. 在工作目錄中修改某些檔案。 2. 對修改後的檔案進行快照，然後儲存到暫存區域。 3. 提交更新，將儲存在暫存區域的檔案快照永久轉儲到 Git 目錄中。
所以，我們可以從檔案所處的位置來判斷狀態：如果是 Git 目錄中儲存著的特定版本檔案，就屬於已提交狀態；如果作了修改並已放入暫存區域，就屬於已暫存狀態；如果自上次取出後，作了修改但還沒有放到暫存區域，就 是已修改狀態。到第二章的時候，我們會進一步瞭解其中細節，並學會如何根據檔案狀態實施後續操作，以及怎樣跳過暫存直接提交。
1.4 安裝 Git
是時候動手嘗試下 Git 了，不過得先安裝好它。有許多種安裝方式，主要分為兩種，一種是通過編譯原始碼來安裝；另一種是使用為特定平臺預編譯好的安裝包。
從原始碼安裝
若是條件允許，從原始碼安裝有很多好處，至少可以安裝最新的版本。Git 的每個版本都在不斷嘗試改進使用者體驗，所以能通過原始碼自己編譯安裝最新版本就再好不過了。有些 Linux 版本自帶的安裝包更新起來並不及時，所以除非你在用最新的 distro 或者 backports，那麼從原始碼安裝其實該算是最佳選擇。
Git 的工作需要呼叫 curl，zlib，openssl，expat，libiconv 等庫的程式碼，所以需要先安裝這些依賴工具。在有 yum 的系統上（比如 Fedora）或者有 apt-get 的系統上（比如 Debian 體系），可以用下面的命令安裝：
$ yum install curl-devel expat-devel gettext-devel \
openssl-devel zlib-devel
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
libz-dev libssl-dev
之後，從下面的 Git 官方站點下載最新版本原始碼：
http://git-scm.com/download
然後編譯並安裝：
$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install
現在已經可以用 git 命令了，用 git 把 Git 專案倉庫克隆到本地，以便日後隨時更新：
$ git clone git://git.kernel.org/pub/scm/git/git.git
在 Linux 上安裝
如果要在 Linux 上安裝預編譯好的 Git 二進位制安裝包，可以直接用系統提供的包管理工具。在 Fedora 上用 yum 安裝：
$ yum install git-core
在 Ubuntu 這類 Debian 體系的系統上，可以用 apt-get 安裝：
$ apt-get install git-core
在 Mac 上安裝
在 Mac 上安裝 Git 有兩種方式。最容易的當屬使用圖形化的 Git 安裝工具，介面如圖 1-7，下載地址在：
http://code.google.com/p/git-osx-installer
圖 1-7. Git OS X 安裝工具
另一種是通過 MacPorts (http://www.macports.org) 安裝。如果已經裝好了 MacPorts，用下面的命令安裝 Git：
$ sudo port install git-core +svn +doc +bash_completion +gitweb
這 種方式就不需要再自己安裝依賴庫了，Macports 會幫你搞定這些麻煩事。一般上面列出的安裝選項已經夠用，要是你想用 Git 連線 Subversion 的程式碼倉庫，還可以加上 +svn 選項，具體將在第八章作介紹。（譯註：還有一種是使用 homebrew（https://github.com/mxcl/homebrew）：brew install git。）
在 Windows 上安裝
在 Windows 上安裝 Git 同樣輕鬆，有個叫做 msysGit 的專案提供了安裝包，可以到 Google Code 的頁面上下載 exe 安裝檔案並執行：
http://code.google.com/p/msysgit
完成安裝之後，就可以使用命令列的 git 工具（已經自帶了 ssh 客戶端）了，另外還有一個圖形介面的 Git 專案管理工具。
1.5 初次執行 Git 前的配置
一般在新的系統上，我們都需要先配置下自己的 Git 工作環境。配置工作只需一次，以後升級時還會沿用現在的配置。當然，如果需要，你隨時可以用相同的命令修改已有的配置。
Git 提供了一個叫做 git config 的工具（譯註：實際是 git-config 命令，只不過可以通過 git 加一個名字來呼叫此命令。），專門用來配置或讀取相應的工作環境變數。而正是由這些環境變數，決定了 Git 在各個環節的具體工作方式和行為。這些變數可以存放在以下三個不同的地方：
· /etc/gitconfig 檔案：系統中對所有使用者都普遍適用的配置。若使用 git config 時用--system 選項，讀寫的就是這個檔案。
· ~/.gitconfig 檔案：使用者目錄下的配置檔案只適用於該使用者。若使用 git config 時用--global 選項，讀寫的就是這個檔案。
· 當前專案的 git 目錄中的配置檔案（也就是工作目錄中的 .git/config 檔案）：這裡的配置僅僅針對當前專案有效。每一個級別的配置都會覆蓋上層的相同配置，所以.git/config 裡的配置會覆蓋/etc/gitconfig 中的同名變數。
在 Windows 系統上，Git 會找尋使用者主目錄下的 .gitconfig 檔案。主目錄即 $HOME 變數指定的目錄，一般都是C:\Documents and Settings\$USER。此外，Git 還會嘗試找尋/etc/gitconfig 檔案，只不過看當初 Git 裝在什麼目錄，就以此作為根目錄來定位。
使用者資訊
第一個要配置的是你個人的使用者名稱稱和電子郵件地址。這兩條配置很重要，每次 Git 提交時都會引用這兩條資訊，說明是誰提交了更新，所以會隨更新內容一起被永久納入歷史記錄：
$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]
如果用了 --global 選項，那麼更改的配置檔案就是位於你使用者主目錄下的那個，以後你所有的專案都會預設使用這裡配置的使用者資訊。如果要在某個特定的專案中使用其他名字或者電郵，只要去掉--global 選項重新配置即可，新的設定儲存在當前專案的.git/config 檔案裡。
文字編輯器
接下來要設定的是預設使用的文字編輯器。Git 需要你輸入一些額外訊息的時候，會自動呼叫一個外部文字編輯器給你用。預設會使用作業系統指定的預設編輯器，一般可能會是 Vi 或者 Vim。如果你有其他偏好，比如 Emacs 的話，可以重新設定：
$ git config --global core.editor emacs
差異分析工具
還有一個比較常用的是，在解決合併衝突時使用哪種差異分析工具。比如要改用 vimdiff 的話：
$ git config --global merge.tool vimdiff
Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff，ecmerge，和 opendiff 等合併工具的輸出資訊。當然，你也可以指定使用自己開發的工具，具體怎麼做可以參閱第七章。
檢視配置資訊
要檢查已有的配置資訊，可以使用 git config --list 命令：
$ git config --list
user.name=Scott Chacon
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...
有時候會看到重複的變數名，那就說明它們來自不同的配置檔案（比如 /etc/gitconfig 和 ~/.gitconfig），不過最終 Git 實際採用的是最後一個。
也可以直接查閱某個環境變數的設定，只要把特定的名字跟在後面即可，像這樣：
$ git config user.name
Scott Chacon
1.6 獲取幫助
想了解 Git 的各式工具該怎麼用，可以閱讀它們的使用幫助，方法有三：
$ git help $ git --help
$ man git-
比如，要學習 config 命令可以怎麼用，執行：
$ git help config
我們隨時都可以瀏覽這些幫助資訊而無需連網。不過，要是你覺得還不夠，可以到 Frenode IRC 伺服器（irc.freenode.NET）上的 #git 或 #github 頻道尋求他人幫助。這兩個頻道上總有著上百號人，大多都有著豐富的 git 知識，並且樂於助人。
1.7 小結
至此，你該對 Git 有了點基本認識，包括它和以前你使用的 CVCS 之間的差別。現在，在你的系統上應該已經裝好了 Git，設定了自己的名字和電郵。接下來讓我們繼續學習 Git 的基礎知識。
Git詳解之二 Git基礎
|
您的評價: |
Git 基礎
讀完本章你就能上手使用 Git 了。本章將介紹幾個最基本的，也是最常用的 Git 命令，以後絕大多數時間裡用到的也就是這幾個命令。讀完本章，你就能初始化一個新的程式碼倉庫，做一些適當配置；開始或停止跟蹤某些檔案；暫存或提交某些更 新。我們還會展示如何讓 Git 忽略某些檔案，或是名稱符合特定模式的檔案；如何既快且容易地撤消犯下的小錯誤；如何瀏覽專案的更新歷史，檢視某兩次更新之間的差異；以及如何從遠端倉庫 拉資料下來或者推資料上去。
2.1 取得專案的 Git 倉庫
有兩種取得 Git 專案倉庫的方法。第一種是在現存的目錄下，通過匯入所有檔案來建立新的 Git 倉庫。第二種是從已有的 Git 倉庫克隆出一個新的映象倉庫來。
在工作目錄中初始化新倉庫
要對現有的某個專案開始用 Git 管理，只需到此專案所在的目錄，執行：
$ git init
初始化後，在當前目錄下會出現一個名為 .git 的目錄，所有 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 傳輸協議。我們會在第四章詳細介紹所有這些協議在伺服器端該如何配置使用，以及各種方式之間的利弊。
2.2 記錄每次更新到倉庫
現在我們手上已經有了一個真實專案的 Git 倉庫，並從這個倉庫中取出了所有檔案的工作拷貝。接下來，對這些檔案作些修改，在完成了一個階段的目標之後，提交本次更新到倉庫。
請記住，工作目錄下面的所有檔案都不外乎這兩種狀態：已跟蹤或未跟蹤。已跟蹤的檔案是指本來就被納入版本控制管理的檔案，在上次快照中有它們的記 錄，工作一段時間後，它們的狀態可能是未更新，已修改或者已放入暫存區。而所有其他檔案都屬於未跟蹤檔案。它們既沒有上次更新時的快照，也不在當前的暫存 區域。初次克隆某個倉庫時，工作目錄中的所有檔案都屬於已跟蹤檔案，且狀態為未修改。
在編輯過某些檔案之後，Git 將這些檔案標為已修改。我們逐步把這些修改過的檔案放到暫存區域，直到最後一次性提交所有這些暫存起來的檔案，如此重複。所以使用 Git 時的檔案狀態變化週期如圖 2-1 所示。
圖 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 ..." 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 ..." to unstage)
#
# new file: README
#
只要在 “Changes to be committed” 這行下面的，就說明是已暫存狀態。如果此時提交，那麼該檔案此時此刻的版本將被留存在歷史記錄中。你可能會想起之前我們使用git init 後就運行了 git add 命令，開始跟蹤當前目錄下的檔案。在 git add 後面可以指明要跟蹤的檔案或目錄路徑。如果是目錄的話，就說明要遞迴跟蹤該目錄下的所有檔案。（譯註：其實git add 的潛臺詞就是把目標檔案快照放入暫存區域，也就是 add file into staged area，同時未曾跟蹤過的檔案標記為需要跟蹤。這樣就好理解後續 add 操作的實際意義了。）
暫存已修改檔案
現在我們修改下之前已跟蹤過的檔案 benchmarks.rb，然後再次執行 status 命令，會看到這樣的狀態報告：
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# new file: README
#
# Changed but not updated:
# (use "git add ..." 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 ..." 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 ..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#
# Changed but not updated:
# (use "git add ..." 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 ..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#
忽略某些檔案
一般我們總會有些檔案無需納入 Git 的管理，也不希望它