前言
在我們使用git的時候用的更新代碼是git fetch，git pull這兩條指令。但是有沒有小伙伴去思考過這兩者的區別呢？有經驗的人總是說最好用git fetch+git merge，不建議用git pull。也有人說git pull=git fetch+git merge，真的是這樣嗎？為什么呢？既然如此為什么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在你本地工作目錄還不至於造成不可挽回的損失，但很多時候我們寧願做的慢一些，也不願意返工重來。