Git與Repo入門

版本控制

　　版本控制是什麼已不用在說了，就是記錄我們對檔案、目錄或工程等的修改歷史，方便檢視更改歷史，備份以便恢復以前的版本，多人協作。。。

一、原始版本控制

　　最原始的版本控制是純手工的版本控制：修改檔案，儲存檔案副本。有時候偷懶省事，儲存副本時命名比較隨意，時間長了就不知道哪個是新的，哪個是老的了，即使知道新舊，可能也不知道每個版本是什麼內容，相對上一版作了什麼修改了，當幾個版本過去後，很可能就是下面的樣子了：

　　

二、本地版本控制

　　手工管理比較麻煩且混亂，所以出現了本地版本控制系統，記錄檔案每次的更新，可以對每個版本做一個快照，或是記錄補丁檔案。比如RCS。

　　

三、集中版本控制

　　但是本地版本控制系統偏向於個人使用，或者多個使用的人必須要使用相同的裝置，如果需要多人協作就不好辦了，於是，集中化的版本控制系統（ Centralized Version Control Systems，簡稱 CVCS ）應運而生，比如Subversion，Perforce。

　　在CVCS中，所有的版本資料都儲存在伺服器上，一起工作的人從伺服器上同步更新或上傳自己的修改。

 　　

　　但是，所有的版本資料都存在伺服器上，使用者的本地裝置就只有自己以前所同步的版本，如果不連網的話，使用者就看不到歷史版本，也無法切換版本驗證問題，或在不同分支工作。。

　　而且，所有資料都儲存在單一的伺服器上，有很大的風險這個伺服器會損壞，這樣就會丟失所有的資料，當然可以定期備份。

四、分散式版本控制

　　針對CVCS的以上缺點，出現了分散式版本控制系統( Distributed Version Control System,簡稱 DVCS )，如GIT，Mercurial。

　　DVCS不是複製指定版本的快照，而是把所有的版本資訊倉庫全部同步到本地，這樣就可以在本地檢視所有版本歷史，可以離線在本地提交，只需在連網時push到相應的伺服器或其他使用者那裡。由於每個使用者那裡儲存的都是所有的版本資料，所以，只要有一個使用者的裝置沒有問題就可以恢復所有的資料。

　　當然，這增加了本地儲存空間的佔用。

　　

GIT

　　必須要了解GIT的原理，才能知道每個操作的意義是什麼，才能更容易地理解在什麼情況下用什麼操作，而不是死記命令。當然，第一步是要獲得一個GIT倉庫。

一、獲得GIT倉庫

　　有兩種獲得GIT倉庫的方法，一是在需要用GIT管理的專案的根目錄執行：

git init

　　執行後可以看到，僅僅在專案目錄多出了一個.git目錄，關於版本等的所有資訊都在這個目錄裡面。

　　另一種方式是克隆遠端目錄，由於是將遠端伺服器上的倉庫完全映象一份至本地，而不是取某一個特定版本，所以用clone而不是checkout：

git clone <url>

二、GIT中版本的儲存

　　記錄版本資訊的方式主要有兩種：

1. 記錄檔案每個版本的快照
2. 記錄檔案每個版本之間的差異

　　GIT採用第一種方式。像Subversion和Perforce等版本控制系統都是記錄檔案每個版本之間的差異，這就需要對比檔案兩版本之間的具體差異，但是GIT不關心檔案兩個版本之間的具體差別，而是關心檔案的整體是否有改變，若檔案被改變，在新增提交時就生成檔案新版本的快照，而判斷檔案整體是否改變的方法就是用SHA-1演算法計算檔案的校驗和。

　　GIT能正常工作完全信賴於這種SHA-1校驗和，當一個檔案的某一個版本被記錄之後會生成這個版本的一個快照，但是一樣要能引用到這個快照，GIT中對快照的引用，對每個版本的記錄標識全是通過SHA-1校驗和來實現的。

　　當一個檔案被改變時，它的校驗和一定會被改變（理論上存在兩個檔案校驗和相同，但機率小到可以忽略不計），GIT就以此判斷檔案是否被修改，及以些記錄不同版本。

　　在工作目錄的檔案可以處於不同的狀態，比如說新新增了一個檔案，GIT發覺了這個檔案，但這個檔案是否要納入GIT的版本控制還是要由我們自己決定，比如編譯生成的中間檔案，我們肯定不想納入版本控制。下面就來看下檔案狀態。

三、GIT檔案操作

　　版本控制就是對檔案的版本控制，對於Linux來說，裝置，目錄等全是檔案，要對檔案進行修改、提交等操作，首先要知道檔案當前在什麼狀態，不然可能會提交了現在還不想提交的檔案，或者要提交的檔案沒提交上。

檔案狀態

　　GIT倉庫所在的目錄稱為工作目錄，這個很好理解，我們的工程就在這裡，工作時也是在這裡做修改。

　　在工作目錄中的檔案被分為兩種狀態，一種是已跟蹤狀態(tracked)，另一種是未跟蹤狀態(untracked)。只有處於已跟蹤狀態的檔案才被納入GIT的版本控制。如下圖：

　　

　　當我們往工作目錄新增一個檔案的時候，這個檔案預設是未跟蹤狀態的，我們肯定不希望編譯生成的一大堆臨時檔案預設被跟蹤還要我們每次手動將這些檔案清除出去。用以下命令可以跟蹤檔案：

git add <file>

　　上圖中右邊3個狀態都是已跟蹤狀態，其中的灰色箭頭只表示untracked<-->tracked的轉換而不是untracked<-->unmodified的轉換，新新增的檔案肯定算是被修改過的。那麼，staged狀態又是什麼呢？這就要搞清楚GIT的三個工作區域：本地資料（倉庫）目錄，工作目錄，暫存區，如下圖所示：

　　

　　git directory就是我們的本地倉庫.git目錄，裡面儲存了所有的版本資訊等內容。

　　working driectory，工作目錄，就是我們的工作目錄，其中包括未跟蹤檔案及已跟蹤檔案，而已跟蹤檔案都是從git directory取出來的檔案的某一個版本或新跟蹤的檔案。

　　staging area，暫存區，不對應一個具體目錄，其時只是git directory中的一個特殊檔案。

　　當我們修改了一些檔案後，要將其放入暫存區然後才能提交，每次提交時其實都是提交暫存區的檔案到git倉庫，然後清除暫存區。而checkout某一版本時，這一版本的檔案就從git倉庫取出來放到了我們的工作目錄。

檔案狀態的檢視

　　那麼，我們怎麼知道當前工作目錄的狀態呢？哪些檔案已被暫存？有哪些未跟蹤的檔案？哪些檔案被修改了？所有這些只需要一個命令，git status，如下圖所示:

　　

　　GIT在這一點做得很好，在輸出每個檔案狀態的同時還說明了怎麼操作，像上圖就有怎麼暫存、怎麼跟蹤檔案、怎麼取消暫存的說明。

檔案暫存

　　在上圖中我們可以很清楚地看到，filea未跟蹤，fileb已被暫存（changes to be committed），但是怎麼還有一個fileb是modified但unstaged呢？這是因為當我們暫存一從此檔案時，暫存的是那一檔案當時的版本，當暫存後再次修改了這個檔案後就會提示這個檔案暫存後的修改是未被暫存的。

　　接下來我們就看怎麼暫存檔案，其實也很簡單，從上圖中可以看到GIT已經提示我們了：use "git add <file>..." to update what will be committed，通過 

git add <file>...

　　就可以暫存檔案，跟蹤檔案同樣是這一個命令。在這個命令中可以使用glob模式匹配，比如"file[ab]"，也可以使用"git add ."新增當前目錄下的所有檔案。

　　取消暫存檔案是 

git reset HEAD <file>...

 　　若修改了一個檔案想還原修改可用

git checkout -- <file>... 

檢視檔案修改後的差異

　　當我們修改過一些檔案之後，我們可能想檢視我們都修改了什麼東西，用"git status"只能檢視對哪些檔案做了改動，如果要看改動了什麼，可以用：

git diff

　　比如下圖：

　　

　　---a表示修改之前的檔案，+++b表示修改後的檔案，上圖表示在fileb的第一行後新增了一行"bb"，原來檔案的第一行擴充套件為了修改後的1、2行。

　　但是，前面我們明明用"git status"看到filesb做了一些修改後暫存了，然後又修改了fileb，理應有兩次修改的，怎麼只有一個？

　　因為"git diff"顯示的是檔案修改後還沒有暫存起來的內容，那如果要比較暫存區的檔案與之前已經提交過的檔案呢，畢竟實際提交的是暫存區的內容，可以用以下命令：

　　

　　/dev/null表示之前沒有提交過這一個檔案，這是將是第一次提交，用：

git diff --staged

　　是等效的，但GIT的版本要大於1.6.1。

　　再次執行"git add"將覆蓋暫存區的內容。

忽略一些檔案

　　如果有一些部件我們不想納入版本控制，也不想在每次"git status"時看到這些檔案的提示，或者很多時候我們為了方便會使用"git add ."新增所有修改的檔案，這時就會新增上一些我們不想新增的檔案，怎麼忽略這些檔案呢？

　　GIT當然提供了方法，只需在主目錄下建立".gitignore"檔案，此檔案有如下規則：

• 所有以#開頭的行會被忽略
• 可以使用glob模式匹配
• 匹配模式後跟反斜槓（/）表示要忽略的是目錄
• 如果不要忽略某模式的檔案在模式前加"!"

　　比如：

# 此為註釋 – 將被 Git 忽略
*.a # 忽略所有 .a 結尾的檔案
!lib.a # 但 lib.a 除外
/TODO # 僅僅忽略專案根目錄下的 TODO 檔案,不包括 subdir/TODO
build/ # 忽略 build/ 目錄下的所有檔案
doc/*.txt # 會忽略 doc/notes.txt 但不包括 doc/server/arch.txt

移除檔案

　　當我們要刪除一個檔案時，我們可能就直接用GUI刪除或者直接rm [file]了，但是看圖：

　　

　　我們需要將檔案新增到暫存區才能提交，而移除檔案後是無法新增到暫存區的，那麼怎麼移除一個檔案讓GIT不再將其納入版本控制呢？上圖中GIT已經給出了說明：

git rm <file>...

　　執行以上命令後提交就可以了，有時我們只是想將一些檔案從版本控制中剔除出去，但仍保留這些檔案在工作目錄中，比如我們一不小心將編譯生成的中間檔案納入了版本控制，想將其從版本控制中剔除出去但在工作目錄中保留這些檔案（不然再次編譯可要花費更多時間了），這時只需要新增"--cached"引數。

　　如果我們之前不是通過"git rm"刪除了很多檔案呢？比如說通過patch或者通過GUI，如果這些檔案命名沒有規則，一個一個地執行"git rm"會搞死人的，這時可以用以下命令：

　　

移動檔案

　　和移除檔案一樣，移動檔案不可以通過GUI直接重命令或用"mv"命令，而是要用"git mv"，不然同移除檔案一樣你會得到如下結果：

　　

　　如果要重新命名檔案可以使用

git mv old_name new_name

　　這個命令等效於

mv old_name new_name

git rm old_name

git add new_name

互動式暫存

　　使用git add -i可以開啟互動式暫存，如圖所示，系統會列出一個功能選單讓選擇將要執行的操作。

　　

移除所有未跟蹤檔案

git clean [options]  一般會加上引數-df，-d表示包含目錄，-f表示強制清除。

儲藏-Stashing

　　可能會遇到這樣的情況，你正在一個分支上進行一個特性的開發，或者一個Bug的修正，但是這時突然有其他的事情急需處理，這時該怎麼辦？不可能就在這個工作進行到一半的分支上一起處理，先把修改的Copy出去？太麻煩了。這種情況下就要用到Stashing了。假如我們現在的工作目錄是這樣子的

$ git status
# On branch master
# Changes to be committed:
#
(use "git reset HEAD <file>..." to unstage)
#
#
modified:
index.html
#
# Changed but not updated:
#
(use "git add <file>..." to update what will be committed)
#
#
modified:
lib/simplegit.rb

　　此時如果想切換分支就可以執行以下命令

$ git stash
Saved working directory and index state \
"WIP on master: 049d078 added the index file"
HEAD is now at 049d078 added the index file
(To restore them type "git stash apply")

　　這時你會發現你的工作目錄變得很乾淨了，就可以隨意切分支進行其他事情的處理了。

　　我們可能不只一次進行"git stash"，通過以下命令可以檢視所有stash列表

$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051... Revert "added file_size"

　　當緊急事情處理完了，需要重新回來這裡進行原來的工作時，只需把Stash區域的內容取出來應用到當前工作目錄就行，命令就是

git stash apply

　　如果不基引數就應用最新的stash，或者可以指定stash的名字，如：stash@{1}，可能通過

git stash show

　　顯示stash的內容具體是什麼，同git stash apply一樣，可以選擇指定stash的名字。

　　git stash apply之後再git stash list會發現，apply後的stash還在stash列表中，如果要將其從stash列表中刪除可以用

git stash drop

　　丟棄這個stash，stash的命令引數都可選擇指定stash名字，否則就是最新的stash。

　　一般情況下apply stash後應該就可以把它從stash列表刪除了，先apply再drop還是比較繁瑣的，使用以下一條命令就可以同時完成這兩個操作

git stash pop

　　如果我們執行git stash時工作目錄的狀態是部分檔案已經加入了暫存區，部分檔案沒有，當我們執行git stash apply之後會發現所有檔案都變成了未暫存的，如果想維持原來的樣子操持原來暫存的檔案仍然是暫存狀態，可以加上--index引數

git stash apply --index

　　還有這麼一種情況，我們把原來的修改stash了，然後修復了其他一些東西並進行了提交，但是，這些提交的檔案有些在之前已經被stash了，那麼git stash apply時就很可能會遇到衝突，這種情況下就可以在stash時所以提交的基礎上新建一個分支，然後再apply stash，當然，這兩個步驟有一人簡單的完成方法

git stash branch <branch name>

四、提交與歷史

　　瞭解了檔案的狀態，我們對檔案進行了必要的修改後，就要把我們所做的修改放入版本庫了，這樣以後我們就可以在需要的時候恢復到現在的版本，而要恢復到某一版，一般需要檢視版本的歷史。

提交

　　提交很簡單，直接執行"git commit"。執行git commit後會呼叫預設的或我們設定的編譯器要我們填寫提示說明，但是提交說明最好按GIT要求填寫：第一行填簡單說明，隔一行填寫詳細說明。因為第一行在一些情況下會被提取使用，比如檢視簡短提交歷史或向別人提交補丁，所以字元數不應太多，40為好。下面看一下檢視提交歷史。

檢視提交歷史

　　檢視提交歷史使用如下圖的命令

　　

　　如圖所示，顯示了作者，作者郵箱，提交說明與提交時間，"git log"可以使用放多引數，比如：

　　

　　僅顯示最新的1個log，用"-n"表示。

　　

　　顯示簡單的SHA-1值與簡單提交說明，oneline僅顯示提交說明的第一行，所以第一行說明最好簡單點方便在一行顯示。

　　"git log --graph"以圖形化的方式顯示提交歷史的關係，這就可以方便地檢視提交歷史的分支資訊，當然是控制檯用字元畫出來的圖形。

　　"git log"的更多引數可以檢視命令幫助。

不經過暫存的提交

　如果我們想跳過暫存區直接提交修改的檔案，可以使用"-a"引數，但要慎重，別一不小心提交了不想提交的檔案

git commit -a

　　如果需要快捷地填寫提交說明可使用"-m"引數

git commit -m 'commit message'

修訂提交

　　如果我們提交過後發現有個檔案改錯了，或者只是想修改提交說明，這時可以對相應檔案做出修改，將修改過的檔案通過"git add"新增到暫存區，然後執行以下命令：

git commit --amend

　　然後修改提交說明覆蓋上次提交，但只能重寫最後一次提交。

重排提交

　　通過衍合(rebase)可以修改多個提交的說明，並可以重排提交歷史，拆分、合併提交，關於rebase在講到分支時再說，這裡先看一下重排提交。

　　假設我們的提交歷史是這樣的：

　　

　　如果我們想重排最後兩個提交的提交歷史，可以藉助互動式rebase命令： 

 git rebase -i HEAD~2 或 git rebase -i 3366e1123010e7d67620ff86040a061ae76de0c8

　　HEAD~2表示倒數第三個提交，這條命令要指定要重排的最舊的提交的父提交，此處要重排Second commit與Third commit，所以要指定Initial commit的Commit ID。如圖所示：

　　

　　註釋部分詳細說明了每個選項的作用，如果我們想互動這兩個提交，只需把開頭的這兩行交換下位置就OK了，交換位置後儲存，然後看下提交歷史：

　　

　　可以看到提交歷史已經變了，而且最新的兩個提交的Commit ID變了，如果這些提交已經push到了遠端伺服器，就不要用這個命令了。

刪除提交與修改提交說明

　　如果要刪除某個提交，只需要刪除相應的行就可以了，而要修改某個提交的提交說明的話，只需要把相應行的pick改為reward。

合併提交-squashing

　　合併提交也很簡單，從註釋中的說明看，只需要把相應的行的pick改為squash就可以把這個提交全併到它上一行的提交中。

拆分提交

　　至於拆分提交，由於Git不可能知道你要做哪裡把某一提交拆分開，把以我們就需要讓Git在需要拆分的提交處停下來，由我們手動修改提交，這時要把pick改為edit，這樣Git在處理到這個提交時會停下來，此時我們就可以進行相應的修改並多次提交來拆分提交。

撤銷提交

　　前面說了刪除提交的方法，但是如果是多人合作的話，如果某個提交已經Push到遠端倉庫，是不可以用那種方法刪除提交的，這時就要撤銷提交

git revert <commit-id>

　　這條命令會把指定的提交的所有修改回滾，並同時生成一個新的提交。

Reset

　　git reset會修改HEAD到指定的狀態，用法為

git reset [options] <commit>

　　這條命令會使HEAD提向指定的Commit，一般會用到3個引數，這3個引數會影響到工作區與暫存區中的修改：

• --soft: 只改變HEAD的State，不更改工作區與暫存區的內容
• --mixed(預設): 撤銷暫存區的修改，暫存區的修改會轉移到工作區
• --hard: 撤銷工作區與暫存區的修改

cherry-pick

　　當與別人和作開發時，會向別人貢獻程式碼或者接收別人貢獻的程式碼，有時候可能不想完全Merge別人貢獻的程式碼，只想要其中的某一個提交，這時就可以使用cherry-pick了。就一個命令

 git cherry-pick <commit-id>

filter-branch

　　這條命令可以修改整個歷史，如從所有歷史中刪除某個檔案相關的資訊，全域性性地更換電子郵件地址。

五、GIT分支

 　　分支被稱之為GIT最強大的特性，因為它非常地輕量級，如果用Perforce等工具應該知道，建立分支就是克隆原目錄的一個完整副本，對於大型工程來說，太費時費力了，而對於GIT來說，可以在瞬間生成一個新的分支，無論工程的規模有多大，因為GIT的分支其實就是一指標而已。在瞭解GIT分支之前，應該先了解GIT是如何儲存資料的。

　　前面說過，GIT儲存的不是檔案各個版本的差異，而是檔案的每一個版本儲存一個快照物件，然後通過SHA-1索引，不只是檔案，包換每個提交都是一個物件並通過SHA-1索引。無論是文字檔案，二進位制檔案還是提交，都是GIT物件。

GIT物件

 　　每個物件(object) 包括三個部分：型別，大小和內容。大小就是指內容的大小，內容取決於物件的型別，有四種型別的物件："blob"、"tree"、 "commit" 和"tag"。

• “blob”用來儲存檔案資料，通常是一個檔案。
• “tree”有點像一個目錄，它管理一些“tree”或是 “blob”（就像檔案和子目錄）
• 一個“commit”指向一個"tree"，它用來標記專案某一個特定時間點的狀態。它包括一些關於時間點的後設資料，如提交時間、提交說明、作者、提交者、指向上次提交（commits）的指標等等。
• 一個“tag”是來標記某一個提交(commit) 的方法。

　　比如說我們執行了以下程式碼進行了一次提交：

$ git add README test.rb LICENSE2
$ git commit -m 'initial commit of my project'

　　現在,Git 倉庫中有五個物件:三個表示檔案快照內容的 blob 物件;一個記錄著目錄樹內容及其中各個檔案對應 blob 物件索引的 tree 物件;以及一個包含指向 tree 物件(根目錄)的索引和其他提交資訊後設資料的 commit 物件。概念上來說,倉庫中的各個物件儲存的資料和相互關係看起來如下圖：

　　

　　如果進行多次提交，倉庫的歷史會像這樣：

　　

分支引用

　　所謂的GIT分支，其實就是一個指向某一個Commit物件的指標，像下面這樣，有兩個分支，master與testing：

　　

　　而我們怎麼知道當前在哪一個分支呢？其實就是很簡單地使用了一個名叫HEAD的指標，如上圖所示。HEAD指標的值可以為一個SHA-1值或是一個引用，看以下例子：

　　

　　git的所有版本資訊都儲存了Working Directory下的.git目錄，而HEAD指標就儲存在.git目錄下，如上圖所有，目前為止已經有3個提交，通過檢視HEAD的值可以看到我們當前在master分支：refs/heads/master，當我們通過git checkout取出某一特定提交後，HEAD的值就是成了我們checkout的提交的SHA-1值。

　　記錄我們當前的位置很簡單，就是能過HEAD指標，HEAD指向某一提交的SHA-1值或是某一分支的引用。

新建分支

git branch <branch-name>

　　有時需要在新建分支後直接切換到新建的分支，可以直接用checkout的-b選項

git checkout -b <branch-name>

刪除分支

git branch -d <branch-name>

　　如果在指定的分支有一些unmerged的提交，刪除分支會失敗，這裡可以使用-D引數強制刪除分支。

git branch -D <branch-name>

檢出分支或提交

　　檢出某一分支或某一提交是同一個命令

git checkout <branch-name> | <commit>

分支合併(merge)

　　當我們新建一個分支進行開發，並提交了幾次更新後，感覺是時候將這個分支的內容合回主線了，這是就可以取出主線分支，然後把分支的更新merge回來：

git checkout master

git merge testing

　　如果master分支是testing分支的直接上游，即從master延著testing分支的提交歷史往前走可以直接走到testing分支的最新提交，那麼系統什麼也不需要做，只需要改變master分支的指標即可，這被稱之為"Fast Forward"。

　　但是，一般情況是這樣的，你取出了最新的master分支，比如說master分支最新的提交是C2（假設共3次提交C0<-C1<-C2)，在此基礎上你新建了分支，當你在分支上提交了C3、C5後想將br1時merge回master時，你發現已經有其他人提交了C4，這時候就不能直接修改master的指標了，不然會丟失別人的提交，這個時候就需要將你新建分支時master所在的提交（C2）後的修改（C4），與你新建分支後在分支上的修改（C3、C5)做合併，將合併後的結果作為一個新的提交提交到master，GIT可以自動推匯出應該基於哪個提交進行合併（C2），如果沒有衝突，系統會自動提交新的提交，如果有衝突，系統會提示你解決衝突，當衝突解決後，你就可以將修改加入暫存區並提交。提交歷史類似下面這樣（圖來自Pro-Git)：

　　

　　merge後的提交是按時間排序的，比如下圖，我們在rename提交處新建分支test，在test上提交Commit from branch test，然後回到master提交commit in master after committing in branch，再將test分支merge進master，這時看提交提交歷史，Commit from branch test是在commit in master...之前的，儘管在master上我們是在rename的基礎上提交的commit in master...而GIT會在最後新增一個新的提交（Merge branch 'test'）表示我們在此處將一個分支merge進來了。這種情況會有一個問題，比如說在rename提交處某人A從你這裡Copy了一個GIT倉庫，然後你release了一個patch（通過git format-patch）給A，這時候test分支還沒有merge進來，所以patch中只包含提交：commit in master...然後你把test分支merge了進來又給了A一個patch，這個patch會包含提交：Commit from branch test，而這個patch是以rename為base的，如果commit in master...和Commit from branch test修改了相同的檔案，則第二次的patch可能會打不上去，因為以rename為base的patch可能在新的Code上找不到在哪個位置應用修改。

　　

分支衍合(rebase)

　　有兩種方法將一個分支的改動合併進另一個分支，一個就是前面所說的分支合併，另一個就是分支衍合，這兩種方式有什麼區別呢？

　　分支合併（merge）是將兩個分支的改動合併到一起，並生成一個新的提交，提交歷史是按時間排序的，即我們實際提交的順序，通過git log --graph或一些圖形化工具，可能很明顯地看到分支的合併歷史，如果分支比較多就很混亂，而且如果以功能點新建分支，等功能點完成後合回主線，由於merge後提交是按提交時間排序的，提交歷史就比較亂，各個功能點的提交混雜在一起，還可能遇到上面提到的patch問題。

　　而分支衍合（rebase）是找到兩個分支的共同祖先提交，將要被rebase進來的分支的提交依次在要被rebase到的分支上重演一遍，即回到兩個分支的共同祖先，將branch（假如叫experiment）的每次提交的差異儲存到臨時檔案裡，然後切換到要衍合入的分支（假如是master），依次應用補丁檔案。experiment上有幾次提交，在master就生成幾次新的提交，而且是連在一起的，這樣合進主線後每個功能點的提交就都在一起，而且提交歷史是線性的

 　　對比merge與rebase的提交歷史會是下圖這樣的（圖來自Pro-GIt）：

　　（merge）

　　（rebase）

 

　　rebase後C3提交就不存在了，取而代之的是C3'，而master也成為了experiment的直接上游，只需一次Fast Forward（git merge）後master就指向了最新的提交，就可以刪除experiment分支了。

衍合--onto

git rebase --onto master server client

　　這條命令的意思是：檢出server分支與client分支共同祖先之後client上的變化，然後在master上重演一遍。

父提交

　　HEAD表示當前所在的提交，如果要檢視當前提交父提交呢？git log檢視提交歷史，顯然太麻煩了，而且輸入一長串的Commit-ID也不是一個令人愉悅的事。這時可藉助兩個特殊的符號：~與^。

　　^ 表示指定提交的父提交，這個提交可能由多個交提交，^之後跟上數字表示第幾個父提交，不跟數字等同於^1。

　　~n相當於n個^，比如~3=^^^，表示第一個父提交的第一個父提交的第一個父提交。

遠端分支

　　遠端分支以(遠端倉庫名)/(分支名)命令，遠端分支在本地無法移動修改，當我們clone一個遠端倉庫時會自動在本地生成一個名叫original的遠端倉庫，下載遠端倉庫的所有資料，並新建一個指向它的分支original/master，但這個分支我們是無法修改的，所以需要在本地重新一個分支，比如叫master，並跟蹤遠端分支。

　　Clone了遠端倉庫後，我們還會在本地新建其他分支，並且可能也想跟蹤遠端分支，這時可以用以下命令：

git checkout -b [branch_name] --track|-t <remote>/<remote-banch>

　　和新建分支的方法一樣，只是加了一個引數--track或其縮寫形式-t，可以指定本地分支的名字，如果不指定就會被命名為remote-branch。

　　要拉取某個遠端倉庫的資料，可以用git fetch:

git fetch <remote>

　　當拉取到了遠端倉庫的資料後只是把資料儲存到了一個遠端分支中，如original/master，而這個分支的資料是無法修改的，此時我們可以把這個遠端分支的資料合併到我們當前分支

git merge <remote>/<remote-branch>

　　如果當前分支已經跟蹤了遠端分支，那麼上述兩個部分就可以合併為一個

git pull

　　當在本地修改提交後，我們可能需要把這些本地的提交推送到遠端倉庫，這裡就可以用git push命令，由於本地可以由多個遠端倉庫，所以需要指定遠端倉庫的名字，並同時指定需要推的本地分支及需要推送到遠端倉庫的哪一個分支

git push <remote> <local-branch>:<remote-branch>

　　如果本地分支與遠端分支同名，命令可以更簡單

git push <remote> <branch-name> 等價於 git push <remote> refs/heads/<branch-name>:refs/for/<branch-name>

　　如果本地分支的名字為空，可以刪除遠端分支。

　　前面說過可以有不止一個遠端分支f，新增遠端分支的方法為

git remote add <short-name> <url>

六、標籤-tag

　　作為一個版本控制工具，針對某一時間點的某一版本打tag的功能是必不可少的，要檢視tag也非常簡單，檢視tag使用如下命令

git tag

　　引數"-l"可以對tag進行過濾

git tag -l "v1.1.*"

　　Git 使用的標籤有兩種型別：輕量級的（lightweight）和含附註的（annotated）。輕量級標籤就像是個不會變化的分支，實際上它就是個指向特定提交物件的引用。而含附註標籤，實際上是儲存在倉庫中的一個獨立物件，它有自身的校驗和資訊，包含著標籤的名字，電子郵件地址和日期，以及標籤說明，標籤本身也允許使用 GNU Privacy Guard (GPG) 來簽署或驗證。

　　輕量級標籤只需在git tag後加上tag的名字，如果tag名字

git tag <tag_name>

　　含附註的標籤需要加上引數-a（annotated），同時加上-m跟上標籤的說明

git tag -a <tag_name> -m "<tag_description>"

　　如果你有自己的私鑰，還可以用 GPG 來簽署標籤，只需要把之前的 -a 改為 -s（signed）

　　檢視標籤的內容用

 git show <tag_name>

　　驗證已簽署的標籤用-v（verify）

git tag -v <tag_name>

　　有時在某一個版本忘記打tag了，可以在後期再補上，只需在打tag時加上commit-id

　　要將tag推送到遠端伺服器上，可以用

git push <remote> <tag_name>

　　或者可以用下面的命令推送所有的tag

git push <remote> --tags

七、Git配置

　　使用"git config"可以配置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 <name>

git config --global user.email <email>

　　文字編輯器也可以配置，比如在git commit的時候就會呼叫我們設定的文字編輯器

git config --global core.editor vim

　　另一個常用的是diff工具，比如我們想用視覺化的對比工具

git config --global merge.tool meld

　　要檢視所有的配置，可以用

git config --list

　　或者可以在git config後加上配置項的名字檢視具體項的配置

git config user.name

　　作為一個懶人，雖然checkout、status等命令只是一個單詞，但是還是嫌太長了，我們還可以給命令設定別名如

git config --global alias.co checkout

　　這樣git co就等於git checkout

　　前面說地，git配置項都儲存在那3個檔案裡，可以直接開啟相應的配置檔案檢視配置，也可以直接修改這些配置檔案來配置git，想刪除某一個配置，直接刪除相應的行就行了

　　

八、其他

　　關於GIT各命令的說明可以檢視相關幫助文件，通過以下方法：

git help <command>或git <command> --help

 REPO

repo start <topic_name>

　　開啟一個新的主題，其實就是每個Project都新建一個分支。

repo init -u <url> [OPTIONS]

　　在當前目錄下初始化repo，會在當前目錄生生成一個.repo目錄，像Git Project下的.git一樣，-u指定url，可以加引數-m指定manifest檔案，預設是default.xml，.repo/manifests儲存manifest檔案。.repo/projects下有所有的project的資料資訊，repo是一系列git project的集合，每個git project下的.git目錄中的refs等目錄都是連結到.repo/manifests下的。

repo manifest

　　可以根據當前各Project的版本資訊生成一個manifest檔案

repo sync [PROJECT1...PROJECTN]

　　同步Code。

repo status

　　檢視本地所有Project的修改，在每個修改的檔案前有兩個字元，第一個字元表示暫存區的狀態。

-	no change	same in HEAD and index
A	added	not in HEAD, in index
M	modified	in HEAD, modified in index
D	deleted	in HEAD, not in index
R	renamed	not in HEAD, path changed in index
C	copied	not in HEAD, copied from another in index
T	mode changed	same content in HEAD and index, mode changed
U	unmerged	conflict between HEAD and index; resolution required

　　每二個字元表示工作區的狀態 

letter	meaning	description
-	new/unknown	not in index, in work tree
m	modified	in index, in work tree, modified
d	deleted	in index, not in work tree

 

repo prune <topic> 

　　刪除已經merge的分支

repo abandon <topic>

　　刪除分支，無論是否merged

repo branch或repo branches

　　檢視所有分支

repo diff

　　檢視修改

repo upload

　　上傳本地提交至伺服器

repo forall [PROJECT_LIST]-c COMMAND

　　對指定的Project列表或所有Project執行命令COMMAND，加上-p引數可列印出Project的路徑。

repo forall -c 'git reset --hard HEAD;git clean -df;git rebase --abort'

　　這個命令可以撤銷整個工程的本地修改。

 

　　說明：文中關於Git的知識大多來自Pro-GIt，這本書感覺不錯，想學習的可以找來看：Pro-Git