Git 分支（分散式版本控制系統）
前言
-
幾乎所有的版本控制系統都以某種形式支援分支。使用分支意味著你可以把你的工作從開發主線上分離開來，以免影響開發主線。在很多版本控制系統中，這是一個略微低效的過程——常常需要完全建立一個原始碼目錄的副本。對於大專案來說，這樣的過程會耗費很多時間。
-
有人把 Git 的分支模型稱為它的“必殺技特性”，也正因為這一特性，使得 Git 從眾多版本控制系統中脫穎而出。為何 Git 的分支模型如此出眾呢？Git 處理分支的方式可謂是難以置信的輕量，建立新分支這一操作幾乎能在瞬間完成，並且在不同分支之間的切換操作也是一樣便捷。與許多其它版本控制系統不同，Git 鼓勵在工作流程中頻繁地使用分支與合併，哪怕一天之內進行許多次。理解和精通這一特性，你便會意識到 Git 是如此的強大而又獨特，並且從此真正改變你的開發方式。
1、分支簡介
-
Git 儲存的不是檔案的變化或者差異，而是一系列不同時刻的檔案快照。在進行提交操作時，Git 會儲存一個提交物件（commit object）。
-
知道了 Git 儲存資料的方式，我們可以很自然的想到該提交物件會包含一個指向暫存內容快照的指標。但不僅僅是這樣，該提交物件還包含了作者的姓名和郵箱、提交時輸入的資訊以及指向它的父物件的指標。首次提交產生的提交物件沒有父物件，普通提交操作產生的提交物件有一個父物件，而由多個分支合併產生的提交物件有多個父物件，
-
為了更加形象地說明，我們假設現在有一個工作目錄，裡面包含了三個將要被暫存和提交的檔案。暫存操作會為每一個檔案計算校驗和（SHA-1 雜湊演算法），然後會把當前版本的檔案快照儲存到 Git 倉庫中（Git 使用 blob 物件來儲存它們），最終將校驗和加入到暫存區域等待提交。
$ git add README test.rb LICENSE $ git commit -m "The initial commit of my project" -
當使用
git commit進行提交操作時，Git 會先計算每一個子目錄的校驗和，然後在 Git 倉庫中這些校驗和儲存為樹物件。隨後，Git 便會建立一個提交物件，它除了包含上面提到的那些資訊外，還包含指向這個樹物件（專案根目錄）的指標。如此一來，Git 就可以在需要的時候重現此次儲存的快照。 -
現在，Git 倉庫中有五個物件：三個 blob 物件（儲存著檔案快照）、一個樹物件（記錄著目錄結構和 blob 物件索引）以及一個提交物件（包含著指向前述樹物件的指標和所有提交資訊）。
-
做些修改後再次提交，那麼這次產生的提交物件會包含一個指向上次提交物件（父物件）的指標。
-
Git 的分支，其實本質上僅僅是指向提交物件的可變指標。Git 的預設分支名字是 master。在多次提交操作之後，你其實已經有一個指向最後那個提交物件的 master 分支。它會在每次的提交操作中自動向前移動。
- Git 的 master 分支並不是一個特殊分支。它就跟其它分支完全沒有區別。之所以幾乎每一個倉庫都有 master 分支，是因為
git init命令預設建立它，並且大多數人都懶得去改動它。
- Git 的 master 分支並不是一個特殊分支。它就跟其它分支完全沒有區別。之所以幾乎每一個倉庫都有 master 分支，是因為
2、分支建立
-
Git 是建立新分支很簡單，它只是為你建立了一個可以移動的新的指標。比如，建立一個 testing 分支，你需要使用 git branch 命令。
# git branch [分支名] $ git branch testing
- 這會在當前所在的提交物件上建立一個指標。
-
Git 有一個名為 HEAD 的特殊指標。請注意它和許多其它版本控制系統（如 Subversion 或 CVS）裡的 HEAD 概念完全不同。在 Git 中，它是一個指標，指向當前所在的本地分支（譯註：將 HEAD 想象為當前分支的別名）。在本例中，你仍然在 master 分支上。 因為
git branch命令僅僅建立一個新分支，並不會自動切換到新分支中去。
-
你可以簡單地使用
git log命令檢視各個分支當前所指的物件。提供這一功能的引數是--decorate。$ git log --oneline --decorate f30ab (HEAD, master, testing) add feature #32 - ability to add new 34ac2 fixed bug #1328 - stack overflow under certain conditions 98ca9 initial commit of my project- 正如你所見，當前 “master” 和 “testing” 分支均指向校驗和以 f30ab 開頭的提交物件。
3、分支切換
-
要切換到一個已存在的分支，你需要使用
git checkout命令。 我們現在切換到新建立的 testing 分支去。# git checkout [分支名] $ git checkout testing-
這樣 HEAD 就指向 testing 分支了。
-
-
那麼，這樣的實現方式會給我們帶來什麼好處呢？現在不妨再提交一次。
$ vim test.rb $ git commit -a -m 'made a change'
-
如圖所示，你的 testing 分支向前移動了，但是 master 分支卻沒有，它仍然指向執行
git checkout時所指的物件。這就有意思了，現在我們切換回 master 分支看看。$ git checkout master- 這條命令做了兩件事。一是使 HEAD 指回 master 分支，二是將工作目錄恢復成 master 分支所指向的快照內容。也就是說，你現在做修改的話，專案將始於一個較舊的版本。本質上來講，這就是忽略 testing 分支所做的修改，以便於向另一個方向進行開發。
-
我們不妨再稍微做些修改並提交。
$ vim test.rb $ git commit -a -m 'made other changes'-
現在，這個專案的提交歷史已經產生了分叉。因為剛才你建立了一個新分支，並切換過去進行了一些工作，隨後又切換回 master 分支進行了另外一些工作。上述兩次改動針對的是不同分支：你可以在不同分支間不斷地來回切換和工作，並在時機成熟時將它們合併起來。而所有這些工作，你需要的命令只有 branch、checkout 和 commit。
-
你可以簡單地使用
git log命令檢視分叉歷史。執行git log --oneline --decorate --graph --all，它會輸出你的提交歷史、各個分支的指向以及專案的分支分叉情況。$ git log --oneline --decorate --graph --all * c2b9e (HEAD, master) made other changes | * 87ab2 (testing) made a change |/ * f30ab add feature #32 - ability to add new formats to the * 34ac2 fixed bug #1328 - stack overflow under certain conditions * 98ca9 initial commit of my project
-
-
-
由於 Git 的分支實質上僅是包含所指物件校驗和（長度為 40 的 SHA-1 值字串）的檔案，所以它的建立和銷燬都異常高效。建立一個新分支就相當於往一個檔案中寫入 41 個位元組（40 個字元和 1 個換行符），如此的簡單能不快嗎？這與過去大多數版本控制系統形成了鮮明的對比，它們在建立分支時，將所有的專案檔案都複製一遍，並儲存到一個特定的目錄。完成這樣繁瑣的過程通常需要好幾秒鐘，有時甚至需要好幾分鐘。所需時間的長短，完全取決於專案的規模。而在 Git 中，任何規模的專案都能在瞬間建立新分支。同時，由於每次提交都會記錄父物件，所以尋找恰當的合併基礎（譯註：即共同祖先）也是同樣的簡單和高效。這些高效的特性使得 Git 鼓勵開發人員頻繁地建立和使用分支。
4、分支合併
-
假設你已經修正了 #53 問題，並且打算將你的工作合併入 master 分支。為此，你需要合併 iss53 分支到 master 分支。你只需要檢出到你想合併入的分支，然後執行
git merge命令。$ git checkout master Switched to branch 'master'# git merge [要合併到當前分支的分支名] $ git merge iss53Merge made by the 'recursive' strategy. index.html | 1 + 1 file changed, 1 insertion(+)-
在這種情況下，你的開發歷史從一個更早的地方開始分叉開來（diverged） 因為，master 分支所在提交併不是 iss53 分支所在提交的直接祖先，Git 不得不做一些額外的工作。出現這種情況的時候，Git 會使用兩個分支的末端所指的快照（C4 和 C5）以及這兩個分支的工作祖先（C2），做一個簡單的三方合併。
-
Git 將三方合併的結果做了一個新的快照並且自動建立一個新的提交指向它。這個被稱作一次合併提交，它的特別之處在於他有不止一個父提交。
-
需要指出的是，Git 會自行決定選取哪一個提交作為最優的共同祖先，並以此作為合併的基礎；這和更加古老的 CVS 系統或者 Subversion（1.5 版本之前）不同，在這些古老的版本管理系統中，使用者需要自己選擇最佳的合併基礎。Git 的這個優勢使其在合併操作上比其他系統要簡單很多。
-
-
有時候合併操作不會如此順利。如果你在兩個不同的分支中，對同一個檔案的同一個部分進行了不同的修改，Git 就沒法乾淨的合併它們。如果你對 #53 問題的修改和有關 hotfix 的修改都涉及到同一個檔案的同一處，在合併它們的時候就會產生合併衝突。
$ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.-
此時 Git 做了合併，但是沒有自動地建立一個新的合併提交。Git 會暫停下來，等待你去解決合併產生的衝突。你可以在合併衝突後的任意時刻使用
git status命令來檢視那些因包含合併衝突而處於未合併（unmerged）狀態的檔案。$ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a") -
任何因包含合併衝突而有待解決的檔案，都會以未合併狀態標識出來。Git 會在有衝突的檔案中加入標準的衝突解決標記，這樣你可以開啟這些包含衝突的檔案然後手動解決衝突。出現衝突的檔案會包含一些特殊區段，看起來像下面這個樣子。
<<<<<<< HEAD:index.html <div id="footer">contact : [email protected]</div> ======= <div id="footer"> please contact us at [email protected] </div> >>>>>>> iss53:index.html -
這表示 HEAD 所指示的版本（也就是你的 master 分支所在的位置，因為你在執行 merge 命令的時候已經檢出到了這個分支）在這個區段的上半部分（======= 的上半部分），而 iss53 分支所指示的版本在 ======= 的下半部分。為了解決衝突，你必須選擇使用由 ======= 分割的兩部分中的一個，或者你也可以自行合併這些內容。例如，你可以通過把這段內容換成下面的樣子來解決衝突。
<div id="footer"> please contact us at [email protected] </div> -
上述的衝突解決方案僅保留了其中一個分支的修改，並且 <<<<<<< , ======= , 和 >>>>>>> 這些行被完全刪除了。 在你解決了所有檔案裡的衝突之後，對每個檔案使用 git add 命令來將其標記為衝突已解決。 一旦暫存這些原本有衝突的檔案，Git 就會將它們標記為衝突已解決。
-
如果你對結果感到滿意，並且確定之前有衝突的的檔案都已經暫存了，這時你可以輸入
git commit來完成合並提交。預設情況下提交資訊看起來像下面這個樣子。Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: index.html #
-
5、分支管理
-
1）刪除分支
# git branch -d [分支名] $ git branch -d iss53 -
2）檢視分支列表
-
1> 如果不加任何引數執行它，會得到當前所有分支的一個列表。
$ git branchiss53 * master testing- 注意 master 分支前的 * 字元：它代表現在檢出的那一個分支（也就是說，當前 HEAD 指標所指向的分支）。這意味著如果在這時候提交，master 分支將會隨著新的工作向前移動。
-
2> 如果需要檢視每一個分支的最後一次提交，可以執行
git branch -v命令。$ git branch -viss53 93b412c fix javascript issue * master 7a98805 Merge branch 'iss53' testing 782fd34 add scott to the author list in the readmes -
3>
--merged與--no-merged這兩個有用的選項可以過濾這個列表中已經合併或尚未合併到當前分支的分支。-
如果要檢視哪些分支已經合併到當前分支，可以執行
git branch --merged。$ git branch --mergediss53 * master- 因為之前已經合併了 iss53 分支，所以現在看到它在列表中。在這個列表中分支名字前沒有 * 號的分支通常可以使用
git branch -d刪除掉；你已經將它們的工作整合到了另一個分支，所以並不會失去任何東西。
- 因為之前已經合併了 iss53 分支，所以現在看到它在列表中。在這個列表中分支名字前沒有 * 號的分支通常可以使用
-
檢視所有包含未合併工作的分支，可以執行
git branch --no-merged。$ git branch --no-mergedtesting-
這裡顯示了其他分支。因為它包含了還未合併的工作，嘗試使用
git branch -d命令刪除它時會失敗。$ git branch -d testing error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'. -
如果真的想要刪除分支並丟掉那些工作，可以使用 -D 選項強制刪除它。
-
-
-
6、分支開發工作流
-
1）長期分支
-
因為 Git 使用簡單的三方合併，所以就算在一段較長的時間內，反覆把一個分支合併入另一個分支，也不是什麼難事。也就是說，在整個專案開發週期的不同階段，你可以同時擁有多個開放的分支；你可以定期地把某些特性分支合併入其他分支中。
-
許多使用 Git 的開發者都喜歡使用這種方式來工作，比如只在 master 分支上保留完全穩定的程式碼——有可能僅僅是已經發布或即將釋出的程式碼。他們還有一些名為 develop 或者 next 的平行分支，被用來做後續開發或者測試穩定性——這些分支不必保持絕對穩定，但是一旦達到穩定狀態，它們就可以被合併入 master 分支了。這樣，在確保這些已完成的特性分支（短期分支，比如之前的 iss53 分支）能夠通過所有測試，並且不會引入更多 bug 之後，就可以合併入主幹分支中，等待下一次的釋出。
-
事實上我們剛才討論的，是隨著你的提交而不斷右移的指標。穩定分支的指標總是在提交歷史中落後一大截，而前沿分支的指標往往比較靠前。
-
通常把他們想象成流水線（work silos）可能更好理解一點，那些經過測試考驗的提交會被遴選到更加穩定的流水線上去。
-
你可以用這種方法維護不同層次的穩定性。一些大型專案還有一個 proposed（建議）或 pu: proposed updates（建議更新）分支，它可能因包含一些不成熟的內容而不能進入 next 或者 master 分支。這麼做的目的是使你的分支具有不同級別的穩定性；當它們具有一定程度的穩定性後，再把它們合併入具有更高級別穩定性的分支中。 再次強調一下，使用多個長期分支的方法並非必要，但是這麼做通常很有幫助，尤其是當你在一個非常龐大或者複雜的專案中工作時。
-
-
2）特性分支
-
特性分支對任何規模的專案都適用。特性分支是一種短期分支，它被用來實現單一特性或其相關工作。也許你從來沒有在其他的版本控制系統（VCS）上這麼做過，因為在那些版本控制系統中建立和合並分支通常很費勁。然而，在 Git 中一天之內多次建立、使用、合併、刪除分支都很常見。
-
你已經在上一節中你建立的 iss53 和 hotfix 特性分支中看到過這種用法。 你在上一節用到的特性分支（iss53 和 hotfix 分支）中提交了一些更新，並且在它們合併入主幹分支之後，你又刪除了它們。這項技術能使你快速並且完整地進行上下文切換（context-switch），因為你的工作被分散到不同的流水線中，在不同的流水線中每個分支都僅與其目標特性相關，因此，在做程式碼審查之類的工作的時候就能更加容易地看出你做了哪些改動。你可以把做出的改動在特性分支中保留幾分鐘、幾天甚至幾個月，等它們成熟之後再合併，而不用在乎它們建立的順序或工作進度。
-
考慮這樣一個例子，你在 master 分支上工作到 C1，這時為了解決一個問題而新建 iss91 分支，在 iss91 分支上工作到 C4，然而對於那個問題你又有了新的想法，於是你再新建一個 iss91v2 分支試圖用另一種方法解決那個問題，接著你回到 master 分支工作了一會兒，你又冒出了一個不太確定的想法，你便在 C10 的時候新建一個 dumbidea 分支，並在上面做些實驗。你的提交歷史看起來像下面這個樣子。
-
現在，假定兩件事情：我們最終決定使用第二個解決方案，即 iss91v2 中的辦法；另外，我們把 dumbidea 分支拿給同事們看了以後，發現它竟然是個天才之作。所以接下來，我們準備拋棄原來的 iss91 分支（實際上會丟棄 C5 和 C6），直接在主幹中併入另外兩個分支。最終的提交歷史將變成圖 3-21 這樣。
-
-
請務必牢記這些分支全部都是本地分支，這一點很重要。當你在使用分支及合併的時候，一切都是在你自己的 Git 倉庫中進行的，完全不涉及與伺服器的互動。
-
7、遠端分支
-
1）遠端分支
-
遠端引用是對遠端倉庫的引用（指標），包括分支、標籤等等。你可以通過
git ls-remote (remote)來顯式地獲得遠端引用的完整列表，或者通過git remote show (remote)獲得遠端分支的更多資訊。然而，一個更常見的做法是利用遠端跟蹤分支。 -
遠端跟蹤分支是遠端分支狀態的引用。它們是你不能移動的本地引用，當你做任何網路通訊操作時，它們會自動移動。
-
它們以 (remote)/(branch) 形式命名。例如，如果你想要看你最後一次與遠端倉庫 origin 通訊時 master 分支的狀態，你可以檢視 origin/master 分支。你與同事合作解決一個問題並且他們推送了一個 iss53 分支，你可能有自己的本地 iss53 分支；但是在伺服器上的分支會指向 origin/iss53 的提交。
-
這可能有一點兒難以理解，讓我們來看一個例子。假設你的網路裡有一個在 git.ourcompany.com 的 Git 伺服器。如果你從這裡克隆，Git 的 clone 命令會為你自動將其命名為 origin，拉取它的所有資料，建立一個指向它的 master 分支的指標，並且在本地將其命名為 origin/master。Git 也會給你一個與 origin 的 master 分支在指向同一個地方的本地 master 分支，這樣你就有工作的基礎。
-
遠端倉庫名字 “origin” 與分支名字 “master” 一樣，在 Git 中並沒有任何特別的含義一樣。同時 “master” 是當你執行
git init時預設的起始分支名字，原因僅僅是它的廣泛使用，“origin” 是當你執行git clone時預設的遠端倉庫名字。如果你執行git clone -o booyah，那麼你預設的遠端分支名字將會是 booyah/master。
- 一次 Git 克隆會建立你自己的本地分支 master 和遠端分支 origin/master，並且將它們都指向 origin 上的 master 分支。
-
如果你在本地的 master 分支做了一些工作，然而在同一時間，其他人推送提交到 git.ourcompany.com 並更新了它的 master 分支，那麼你的提交歷史將向不同的方向前進。也許，只要你不與 origin 伺服器連線，你的 origin/master 指標就不會移動。
-
如果要同步你的工作，執行
git fetch origin命令。這個命令查詢 “origin” 是哪一個伺服器（在本例中，它是 git.ourcompany.com），從中抓取本地沒有的資料，並且更新本地資料庫，移動 origin/master 指標指向新的、更新後的位置。
-
為了演示有多個遠端倉庫與遠端分支的情況，我們假定你有另一個內部 Git 伺服器，僅用於你的 sprint 小組的開發工作。這個伺服器位於 git.team1.ourcompany.com。你可以執行
git remote add命令新增一個新的遠端倉庫引用到當前的專案，這個命令我們會在 Git 基礎中詳細說明。將這個遠端倉庫命名為 teamone，將其作為整個 URL 的縮寫。
-
現在，可以執行 git fetch teamone 來抓取遠端倉庫 teamone 有而本地沒有的資料。 因為那臺伺服器上現有的資料是 origin 伺服器上的一個子集，所以 Git 並不會抓取資料而是會設定遠端跟蹤分支 teamone/master 指向 teamone 的 master 分支。
-
-
2）推送分支
-
當你想要公開分享一個分支時，需要將其推送到有寫入許可權的遠端倉庫上。本地的分支並不會自動與遠端倉庫同步，你必須顯式地推送想要分享的分支。這樣，你就可以把不願意分享的內容放到私人分支上，而將需要和別人協作的內容推送到公開分支。
-
如果希望和別人一起在名為 serverfix 的分支上工作，你可以像推送第一個分支那樣推送它。執行
git push [remote] [branch]。# git push [remote] [branch] $ git push origin serverfixCounting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix- 這裡有些工作被簡化了。Git 自動將 serverfix 分支名字展開為 refs/heads/serverfix:refs/heads/serverfix，那意味著，“推送本地的 serverfix 分支來更新遠端倉庫上的 serverfix 分支。”
-
你也可以執行以下命令，它會做同樣的事，相當於它說，“推送本地的 serverfix 分支，將其作為遠端倉庫的 serverfix 分支” 可以通過這種格式來推送本地分支到一個命名不相同的遠端分支。
# git push [remote] [branch]:[remote-branch] $ git push origin serverfix:serverfix- 如果並不想讓遠端倉庫上的分支叫做 serverfix，可以執行
git push origin serverfix:awesomebranch來將本地的 serverfix 分支推送到遠端倉庫上的 awesomebranch 分支。
- 如果並不想讓遠端倉庫上的分支叫做 serverfix，可以執行
-
下一次其他協作者從伺服器上抓取資料時，他們會在本地生成一個遠端分支 origin/serverfix，指向伺服器的 serverfix 分支的引用。
$ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix -
要特別注意的一點是當抓取到新的遠端跟蹤分支時，本地不會自動生成一份可編輯的副本（拷貝）。換一句話說，這種情況下，不會有一個新的 serverfix 分支，只有一個不可以修改的 origin/serverfix 指標。可以執行
git merge origin/serverfix將這些工作合併到當前所在的分支。如果想要在自己的 serverfix 分支上工作，可以將其建立在遠端跟蹤分支之上。# git checkout -b [branch] [remotename]/[branch] $ git checkout -b serverfix origin/serverfixBranch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'- 這會給你一個用於工作的本地分支，並且起點位於 origin/serverfix。
-
-
3）跟蹤分支
-
從一個遠端跟蹤分支檢出一個本地分支會自動建立一個叫做 “跟蹤分支”（有時候也叫做 “上游分支”）。跟蹤分支是與遠端分支有直接關係的本地分支。 如果在一個跟蹤分支上輸入
git pull，Git 能自動地識別去哪個伺服器上抓取、合併到哪個分支。 -
當克隆一個倉庫時，它通常會自動地建立一個跟蹤 origin/master 的 master 分支。然而，如果你願意的話可以設定其他的跟蹤分支，其他遠端倉庫上的跟蹤分支，或者不跟蹤 master 分支。最簡單的就是之前看到的例子，執行
git checkout -b [branch] [remotename]/[branch]。 這是一個十分常用的操作所以 Git 提供了--track快捷方式。# git checkout --track [remotename]/[branch] $ git checkout --track origin/serverfixBranch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' -
如果想要將本地分支與遠端分支設定為不同名字，你可以輕鬆地增加一個不同名字的本地分支的上一個命令。
# git checkout -b sf [remotename]/[branch] $ git checkout -b sf origin/serverfixBranch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'- 現在，本地分支 sf 會自動從 origin/serverfix 拉取。
-
設定已有的本地分支跟蹤一個剛剛拉取下來的遠端分支，或者想要修改正在跟蹤的上游分支，你可以在任意時間使用
-u或--set-upstream-to選項執行git branch來顯式地設定。$ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. -
如果想要檢視設定的所有跟蹤分支，可以使用
git branch的-vv選項。這會將所有的本地分支列出來並且包含更多的資訊，如每一個分支正在跟蹤哪個遠端分支與本地分支是否是領先、落後或是都有。$ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets master 1ae2a45 [origin/master] deploying index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it testing 5ea463a trying something new-
這裡可以看到 iss53 分支正在跟蹤 origin/iss53 並且 “ahead” 是 2，意味著本地有兩個提交還沒有推送到伺服器上。也能看到 master 分支正在跟蹤 origin/master 分支並且是最新的。接下來可以看到 serverfix 分支正在跟蹤 teamone 伺服器上的 server-fix-good 分支並且領先 3 落後 1，意味著伺服器上有一次提交還沒有合併入同時本地有三次提交還沒有推送。最後看到 testing 分支並沒有跟蹤任何遠端分支。
-
需要重點注意的一點是這些數字的值來自於你從每個伺服器上最後一次抓取的資料。這個命令並沒有連線伺服器，它只會告訴你關於本地快取的伺服器資料。如果想要統計最新的領先與落後數字，需要在執行此命令前抓取所有的遠端倉庫。可以像這樣做：
$ git fetch --all;git branch -vv。
-
-
-
4）拉取分支
-
當
git fetch命令從伺服器上抓取本地沒有的資料時，它並不會修改工作目錄中的內容。它只會獲取資料然後讓你自己合併。然而，有一個命令叫作git pull在大多數情況下它的含義是一個git fetch緊接著一個 git merge 命令。如果有一個像之前章節中演示的設定好的跟蹤分支，不管它是顯式地設定還是通過clone或checkout命令為你建立的，git pull都會查詢當前分支所跟蹤的伺服器與分支，從伺服器上抓取資料然後嘗試合併入那個遠端分支。 -
由於
git pull的魔法經常令人困惑所以通常單獨顯式地使用fetch與merge命令會更好一些。
-
-
5）刪除遠端分支
-
假設你已經通過遠端分支做完所有的工作了，也就是說你和你的協作者已經完成了一個特性並且將其合併到了遠端倉庫的 master 分支（或任何其他穩定程式碼分支）。可以執行帶有
--delete選項的git push命令來刪除一個遠端分支。如果想要從伺服器上刪除 serverfix 分支，執行下面的命令。# git push [remotename] --delete [branch] $ git push origin --delete serverfixTo https://github.com/schacon/simplegit - [deleted] serverfix- 基本上這個命令做的只是從伺服器上移除這個指標。Git 伺服器通常會保留資料一段時間直到垃圾回收執行，所以如果不小心刪除掉了，通常是很容易恢復的。
-