在我們使用git的時候用的更新**是git fetch，git pull這兩條指令。但是有沒有小夥伴去思考過這兩者的區別呢？有經驗的人總是說最好用git fetch+git merge，不建議用git pull。也有人說git pull=git fetch+git merge，真的是這樣嗎？為什麼呢？既然如此為什麼git還要提供這兩種方式呢？
首先在作用上他們的功能是大致相同的，都是起到了更新**的作用。
下面通過示例，講解他們的區別。
首先我們要說簡單說git的執行機制。git分為本地倉庫和遠端倉庫，我們一般情況都是寫完**，commit到本地倉庫（生成本地倉的commit id，代表當前提交**的版本號），然後push到遠端倉庫（記錄這個版本號），這個流程大家都熟悉。
我們本地的git資料夾裡面對應也儲存了git本地倉庫master分支的commit id 和 跟蹤的遠端分支orign/master的commit id（可以有多個遠端倉庫）。那什麼是跟蹤的遠端分支呢，開啟git資料夾可以看到如下檔案：
.git/refs/head/[本地分支]
.git/refs/remotes/[正在跟蹤的分支]
但是，不管他們是如何的相似，他們還是有乙個重大的區別：更改遠端跟蹤分支只能用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，然後我們要更新**。
使用git fetch更新**，本地的庫中master的commitid不變，還是等於1。但是與git上面關聯的那個orign/master的commit id變成了2。這時候我們本地相當於儲存了兩個**的版本號，我們還要通過merge去合併這兩個不同的**版本，如果這兩個版本都修改了同一處的**，這時候merge就會出現衝突，然後我們解決衝突之後就生成了乙個新的**版本。
這時候本地的**版本可能就變成了commit id=3，即生成了乙個新的**版本。
相當於fetch的時候本地的master沒有變化，但是與遠端倉關聯的那個版本號被更新了，我們接下來就是在本地合併這兩個版本號的**。
是用git pull更新**的話就比較簡單暴力了，看下圖。
使用git pull的會將本地的**更新至遠端倉庫裡面最新的**版本。
由此可見，git pull看起來像git fetch+git merge，但是根據commit id來看的話，他們實際的實現原理是不一樣的。
Git fetch和git pull的區別
原文 git中從遠端的分支獲取最新的版本到本地有這樣2個命令 1.git fetch 相當於是從遠端獲取最新版本到本地，不會自動merge git fetch origin master git log p master origin master git merge origin master 以...
Git fetch和git pull的區別
git中從遠端的分支獲取最新的版本到本地有這樣2個命令 1.git fetch 相當於是從遠端獲取最新版本到本地，不會自動merge git fetch origin master git log p master origin master git merge origin master 以上命令...
Git fetch和git pull的區別
git中從遠端的分支獲取最新的版本到本地有這樣2個命令 1.git fetch 相當於是從遠端獲取最新版本到本地，不會自動merge git fetch origin master git log p master.origin master git merge origin mastergit f...