在 Day 18 的內容中，提到了可以使用 git push 指令把本地的儲存庫發送到共同的儲存庫中心，那麼共用儲存庫與本地儲存庫之間要怎麼溝通呢？

這個所謂的溝通，也可以把它想像成就是兩地儲存庫的物件同步，使本地與共用儲存庫都有一樣的 commit、一樣的 HASD Code、一樣的 GIT 物件。

我們回到 GIT 的三個區域，當執行 git push -u origin master  的時候， GIT 的區域模型發生了什麼事情呢？

• 首先在是 push 指令，會往設定的遠端 origin 發送
  

• 而後，因為 origin 參數後面帶了 master 所以到遠端後，會知道，目前發送過來的 GIT 物件，是要放在遠端上的 master 這個分支。
  

• 接著依序把目前本地有的物件送到遠端的 master 這個分支上。
  

• 接著為了方便記憶遠端分支上面的狀態，GIT 會在本地的儲存庫上，也新增一個紀錄遠端狀態的分支，通常這個分支名稱會標示為 origin/master ，代表著遠端目前 master 分支，指在什麼位置。
  

• 直接使用 HASH Code 呈現的方法，可以想像，在 git push 完畢之後，在本地會建立一個 origin/master 貼紙，指在跟本地 master 分支一樣的位置。

• 如果硬要用動畫呈現，git push -u origin master 之後，本地的分支大概會長這樣。就是多了一個分支貼紙。

如果本地現在多了一個 commit 名稱為 HASH D 呢？

一樣的，我們使用 git push 這個指令，而因為上面以及使用了 -u 設定了本地 master對應的遠端 origin 的 master 分支，所以只需要下 git push 指令，不再需要接其他參數。現在，本地因為有遠端目前的分支的狀態 (通常在 git push 之前，會至少先使用 git fetch 指令，取得遠端狀態，這邊先假設遠端沒有任何變化。)，所以知道，目前本地比遠端多了一個 HASH D 這個 Commit，因此這時候只需要傳送 HASH D 到遠端，傳送完畢後，只需要把 origin/master 這個分支貼紙，往下移動到根本地 master 分支一樣的位置。

如果以動畫表示在 git push 之後，本地分支的變化，概略可以用底下的動畫表示。

如果是遠端的儲存庫比本地的儲存庫多了新的 commit (HASH D) ，那本地應該要怎麼知道？談 git fetch

在 GIT 系統中，要跟遠端取得遠端多的物件，就是使用 git fetch 指令，這時候，因為目前操作的 master 分支已經在 git push 的時候，設定了對應，因此一樣不需要再設定其他參數。

• 要取得 Server 端新的物件狀態，可以使用 git fetch 指令。
  

• 當執行完畢 git fetch 指令之後，本地的 origin/master 分之，在取得 HASH D 之後，會連帶的把本地 origin/master 這個分支貼紙，往 HASH D 移動，完成 fetch 動作。
  

• 如果只看 git fetch 的本地 master 分支變化，概略如下動畫：
  

總結：

為什麼會把 git 與遠端溝通操作的過程留在 Day 20 才講，主要是因為，看完上面的說明之後，會發現，對於本地而言， GIT 與遠端的操作，無論是 git push 或是 git fetch，對於本地，都只是一個分支貼紙的操作，所以在講與遠端溝通之前，先把 git merge、git rebase 等指令先講了一次。

至於與遠端同步儲存庫物件、溝通時，如果遇到衝突該怎麼處理，就留待下一篇繼續說明。