git pull(git pull和git fetch的區別)

前言

在我們使用git的時候用的更新代碼是git fetch，git pull這兩條指令。但是有沒有小伙伴去思考過這兩者的區別呢？有經驗的人總是說最好用git fetch+git merge，不建議用git pull。也有人說git pull=git fetch+git merge，真的是這樣嗎？為什么呢？既然如此為什么git還要提供這兩種方式呢？git深入學習

1. 相同點

首先在作用上他們的功能是大致相同的，都是起到了更新代碼的作用。

2. 不同點

先補充一些git里面相關的一些知識：

首先我們要說簡單說git的運行機制。git分為本地倉庫和遠程倉庫，我們一般情況都是寫完代碼，commit到本地倉庫（生成本地倉的commit ID，代表當前提交代碼的版本號），然后push到遠程倉庫（記錄這個版本號），這個流程大家都熟悉。

我們本地的git文件夾里面對應也存儲了git本地倉庫master分支的commit ID 和 跟蹤的遠程分支orign/master的commit ID（可以有多個遠程倉庫）。那什么是跟蹤的遠程分支呢，打開git文件夾可以看到如下文件：

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

其中head就是本地分支，remotes是跟蹤的遠程分支，這個類型的分支在某種類型上是十分相似的，他們都是表示提交的SHA1校驗和（就是commitID）。

但是，不管他們是如何的相似，他們還是有一個重大的區別：

更改遠端跟蹤分支只能用git fetch，或者是git push后作為副產品（side-effect）來改變。我們無法直接對遠程跟蹤分支操作，我們必須先切回本地分支然后創建一個新的commit提交。

首先假設我們本地倉庫的 master 分支上 commit ID =1 ，orign/mastter中的commit ID =1 ;這時候遠程倉庫有人更新了github ogirn庫中master分支上的代碼，新的代碼版本號commit ID =2 ,那么在github上 orign/master的commitID=2，然后我們要更新代碼。

1. git fetch

使用git fetch更新代碼，本地的庫中master的commitID不變，還是等于1。但是與git上面關聯的那個orign/master的commit ID變成了2。這時候我們本地相當于存儲了兩個代碼的版本號，我們還要通過merge去合并這兩個不同的代碼版本，如果這兩個版本都修改了同一處的代碼，這時候merge就會出現沖突，然后我們解決沖突之后就生成了一個新的代碼版本。

這時候本地的代碼版本可能就變成了commit ID=3，即生成了一個新的代碼版本。

相當于fetch的時候本地的master沒有變化，但是與遠程倉關聯的那個版本號被更新了，我們接下來就是在本地合并這兩個版本號的代碼。

2. git pull

是用git pull更新代碼的話就比較簡單暴力了，看下圖。

使用git pull的會將本地的代碼更新至遠程倉庫里面最新的代碼版本

3. 總結

由此可見，git pull看起來像git fetch+get merge，但是根據commit ID來看的話，他們實際的實現原理是不一樣的。

這里借用之前文獻看到的一句話：

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

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

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

結語：

碼字不易看到最后了，那就點個關注唄，只收藏不點關注的都是在耍流氓！有了您的支持，我們會做得更好！

關注并私信我“架構”，免費送一些Java架構資料，先到先得！