Git 少用 Pull 多用 Fetch 和 Merge

至尊王者發表於2013-11-05

本文有點長而且有點亂,但就像Mark Twain Blaise Pascal笑話裡說的那樣:我沒有時間讓它更短些。在Git的郵件列表裡有很多關於本文的討論,我會盡量把其中相關的觀點列在下面。

我最常說的關於git使用的一個經驗就是:

不要用git pull,用git fetch和git merge代替它。

git pull的問題是它把過程的細節都隱藏了起來,以至於你不用去了解git中各種型別分支的區別和使用方法。當然,多數時候這是沒問題的,但一旦程式碼有問題,你很難找到出錯的地方。看起來git pull的用法會使你吃驚,簡單看一下git的使用文件應該就能說服你。

將下載(fetch)和合並(merge)放到一個命令裡的另外一個弊端是,你的本地工作目錄在未經確認的情況下就會被遠端分支更新。當然,除非你關閉所有的安全選項,否則git pull在你本地工作目錄還不至於造成不可挽回的損失,但很多時候我們寧願做的慢一些,也不願意返工重來。

分支(Branches)

在說git pull之前,我們需要先澄清分支的概念(branches)。很多人像寫程式碼似的用一行話來描述分支是什麼,例如:

  • 準確而言,分支的概念不是一條線,而類似於開發中的有向無環圖
  • 分支類似於一個重量級的大物件集合。

我認為你應該這樣來理解分支的概念:它是用來標記特定的程式碼提交,每一個分支通過SHA1sum值來標識,所以對分支進行的操作是輕量級的--你改變的僅僅是SHA1sum值。

這個定義或許會有意想不到的影響。比如,假設你有兩個分支,“stable” 和 “new-idea”, 它們的頂端在版本 E 和 F:

  A-----C----E ("stable")
   \
    B-----D-----F ("new-idea")

所以提交(commits) A, C和 E 屬於“stable”,而 A, B, D 和 F 屬於 “new-idea”。如果之後你用下面的命令 將“new-idea” merge 到 “stable” :

    git checkout stable   # Change to work on the branch "stable"
    git merge new-idea    # Merge in "new-idea"

…那麼你會得到這個:

  A-----C----E----G ("stable")
   \             /
    B-----D-----F ("new-idea")

要是你繼續在“new idea” 和“stable”分支提交, 會得到:

  A-----C----E----G---H ("stable")
   \             /
    B-----D-----F----I ("new-idea")

因此現在A, B, C, D, E, F, G 和 H 屬於 “stable”,而A, B, D, F 和 I 屬於 “new-idea”。

當然了,分支確實有些特殊的屬性——其中最重要的是,如果你在一個分支進行作業並建立了一個新的提交(commits),該分支的頂端將前進到那個提交(commits)。這正是你所希望的。當用git merge 進行合併(merge)的時候,你只是指定了要合併到當前分支的那個併入分支,以及當前分支的當前進展。

另一個表明使用分支會有很大幫助的觀點的常見情形是:假設你直接工作在一個專案的主要分支(稱為“主版本”),當你意識到你所做的可能是一個壞主意時已經晚了,這時你肯定寧願自己是工作在一個主題分支上。如果提交圖看起來像這樣:

   last version from another repository
      |
      v
  M---N-----O----P---Q ("master")

那麼你把你的工作用下面的一組命令分開做(如圖顯示的是執行它們之後所更改的狀態):

  git branch dubious-experiment

  M---N-----O----P---Q ("master" and "dubious-experiment")

  git checkout master

  # Be careful with this next command: make sure "git status" is
  # clean, you're definitely on "master" and the
  # "dubious-experiment" branch has the commits you were working
  # on first...

  git reset --hard <SHA1sum of commit N>

       ("master")
  M---N-------------O----P---Q ("dubious-experiment")

  git pull # Or something that updates "master" from
           # somewhere else...

  M--N----R---S ("master")
      \
       O---P---Q ("dubious-experiment")

這是個看起來我最終做了很多的事情。

分支型別

分支這個術語不太容易理解,而且在git的開發過程中發生了很多變化。但簡單來說git的分支只有兩種:

a)“本地分支(local branches)” ,當你輸入“git branch”時顯示的。例如下面這個小例子:

       $ git branch
         debian
         server
       * master

b)“遠端跟蹤分支(Remote-tracking branches)” ,當你輸入“git branch -r”是顯示的,如:

 

       $ git branch -r
       cognac/master
       fruitfly/server
       origin/albert
       origin/ant
       origin/contrib
       origin/cross-compile

從上面的輸出可以看到,跟蹤分支的名稱前有一個“遠端的”標記名稱(如 :origin, cognac, fruitfly)後面跟一個“/”,然後遠端倉庫裡分支的真正名稱。(“遠端名稱”是一個程式碼倉庫別名,和本地目錄或URL是一個含義,你可以通過"git remote"命令自由定義額外的“遠端名稱”。但“git clone”命令預設使用的是“origin”這個名稱。)

如果你對分支在本地是如何儲存感興趣的話,看看下面檔案: 

  •   .git/refs/head/[本地分支]
  •   .git/refs/remotes/[正在跟蹤的分支]

兩種型別的分支在某些方面十分相似-它們都只是在本地儲存一個表示提交的SHA1校驗和。(我強調“本地”,因為許多人看到"origin/master" 就認為這個分支在某種意義上說是不完整的,沒有訪問遠端伺服器的許可權- 其實不是這種情況。) 
不管如何相似,它們還是有一個特別重大的區別: 

  •   更改遠端跟蹤分支的安全方法是使用git fetch或者是作為git-push副產品,你不能直接對遠端跟蹤分支這麼操作。相反,你總得切換到本地分支,然後建立可移動到分支頂端的新提交 。

因此,你對遠端跟蹤分支最多能做的是下面事情中的一件: 

    •  使用git fetch 更新遠端跟蹤分支
    •  合併遠端跟蹤分支到當前分支
    •  根據遠端跟蹤分支建立本地分支

基於遠端跟蹤分支建立本地分支

如果你想基於遠端跟蹤分支建立本地分支(在本地分支上工作),你可以使用如下命令:git branch –trackgit checkout –track -b,兩個命令都可以讓你切換到新建立的本地分支。例如你用git branch -r命令看到一個遠端跟蹤分支的名稱為“origin/refactored”是你所需要的,你可以使用下面的命令:

    git checkout --track -b refactored origin/refactored

在上面的命令裡,“refactored”是這個新分支的名稱,“origin/refactored”則是現存遠端跟蹤分支的名稱。(在git最新的版本里,例子中‘-track’選項已經不需要了,如果最後一個引數是遠端跟蹤分支,這個引數會被預設加上。)

“–track”選項會設定一些變數,來保持本地分支和遠端跟蹤分支的相關性。他們對下面的情況很有用:

  • git pull命令下載新的遠端跟蹤分支之後,可以知道合併到哪個本地分支裡
  • 使用git checkout檢查本地分支時,可以輸出一些有用的資訊:
    Your branch and the tracked remote branch 'origin/master'
    have diverged, and respectively have 3 and 384 different
    commit(s) each.

或者:

    Your branch is behind the tracked remote branch
    'origin/master' by 3 commits, and can be fast-forwarded.

允許使用的配置變數是:“branch.<local-branch-name>.merge”和“branch.<local-branch-name>.remote”,但通常情況下你不用考慮他們的設定。

當從遠端程式碼倉庫建立一個本地分支之後,你會注意到,“git branch -r”能列出很多遠端跟蹤分支,但你的電腦上只有一個本地分支,你需要給上面的命令設定一個引數,來指定本地分支和遠端分支的對應。

有一些術語上的說法容易混淆需要注意一下:“track”在當作引數"-track"使用時,意思指通過本地分支對應一個遠端跟蹤分支。在遠端跟蹤分支中則指遠端程式碼倉庫中的跟蹤分支。有點繞口。。。

下面我們來看一個例子,如何從遠端分支中更新原生程式碼,以及如何把本地分支推送到一個新的遠端倉庫中。

從遠端倉庫進行更新

如果我想從遠端的源倉庫更新到本地的程式碼倉庫,可以輸入“git fetch origin”的命令,該命令的輸入類似如下格式:

  remote: Counting objects: 382, done.
  remote: Compressing objects: 100% (203/203), done.
  remote: Total 278 (delta 177), reused 103 (delta 59)
  Receiving objects: 100% (278/278), 4.89 MiB | 539 KiB/s, done.
  Resolving deltas: 100% (177/177), completed with 40 local objects.
  From ssh://longair@pacific.mpi-cbg.de/srv/git/fiji
     3036acc..9eb5e40  debian-release-20081030 -> origin/debian-release-20081030
   * [new branch]      debian-release-20081112 -> origin/debian-release-20081112
   * [new branch]      debian-release-20081112.1 -> origin/debian-release-20081112.1
     3d619e7..6260626  master     -> origin/master

最重要的是這兩行:

     3036acc..9eb5e40  debian-release-20081030 -> origin/debian-release-20081030
   * [new branch]      debian-release-20081112 -> origin/debian-release-20081112

第一行表明遠端的origin/debian-release-20081030分支的提交(commit)ID已經從3036acc更新為9eb5e40。箭頭前的部分是遠端分支的名稱。第二行是我們採取的動作,建立遠端跟蹤分支(如果遠端倉庫有新的tags,git fetch也會一併下載到本地)。

前面那些行顯示出“git fetch”命令會將哪些檔案下載到本地,這些檔案一旦下載到本地之後,就可以在本地進行任意操作了。

“git fetch”命令執行完畢之後,還不會立即將下載的檔案合併到你當前工作目錄裡,這就給你了一個選擇下一步操作的機會,要是想將從遠端分支下載的檔案更新到你的工作目錄裡,你需要執行一個“合併(merge)”操作。例如,我當前的本地分支為”master“(執行git checkout master後),這時我想執行合併操作:

    git merge origin/master

幾句題外話:合併的時候有可能你還沒有對遠端分支提交過任何的更改,或者可能是一個複雜的合併。)

如果你只是想看看本地分支和遠端分支的差異,你可以使用下面的命令:

git diff master origin/master

單獨進行下載和合並是一個好的做法,你可以先看看下載的是什麼,然後再決定是否和原生程式碼合併。而且分開來做,可以清晰的區別開本地分支和遠端分支,方便選擇使用。

 

把你的變更推送到一個遠端倉庫

如何通過其他的方式呢? 假設你對 “experimental”分支做了變更並且希望把他push到"origin"遠端倉庫中去. 你可以這樣做:

1 git push origin experimental

 

你可能將會收到:遠端倉庫無法fast-forward該分支的錯誤資訊, 這將意味著可能有別人push了不同的變更到了這個分支上.所以,你需要fetch和merge別人的變更並再次嘗試push操作.

擴充套件閱讀: 如果這個分支在遠端倉庫裡對應不同的名稱(如:experiment-by-bob),你應該這麼做: 
git push origin experimental:experiment-by-bob

在舊版本的git裡,如果“experiment-by-bob”不存在,命令應該這麼寫: 
      git push origin experimental:refs/heads/experiment-by-bob

這樣會首先建立遠端分支。但git 1.6.1.2應該就不用這麼做了。參加下面Sitaram’s的評論。 
 如果本地分支和遠端分支名稱相同,不需要特殊說明系統將會自動建立這個分支,就像常規的git push操作一樣。 

在實際應用中,保持名稱相同可以減少混淆,因此“本地名稱和遠端名稱”作為“refspec”引數,我們不會進行更多的討論。

git push的操作不會牽扯遠端跟蹤分支(origin/experimental,只有在你下次進行git fetch時才會被更新。

上面這個說法不對,根據Deskin Miller的評論糾正:當推送到對應的遠端分支後,你的遠端跟蹤分支就會被更新。

為什麼不用 git 的 pull?

雖然 git pull 大部分時候是好的,特別是如果你用CVS型別的方式使用Git時,它可能正適合你。然而,如果你想用一個更地道的方式(建立很多主題分支,當你需要時隨時改寫本地歷史,等等)使用Git,那麼習慣把 git fetch 和 git merge 分開做會有很大幫助。

相關文章