git pull和git fetch的區別（轉）

前言

在咱們使用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+git merge，可是根據commit ID來看的話，他們實際的實現原理是不同的。
• 這裏借用以前文獻看到的一句話：

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

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

將下載（fetch）和合並（merge）放到一個命令裏的另一個弊端是，你的本地工做目錄在未經確認的狀況下就會被遠程分支更新。固然，除非你關閉全部的安全選項，不然git pull在你本地工做目錄還不至於形成不可挽回的損失，但不少時候咱們寧願作的慢一些，也不肯意返工重來 。

轉自https://blog.csdn.net/weixin_41975655/article/details/82887273