我最常說的關於git使用的一個經驗就是： 不要用git pull，用git fetch和git merge代替它。
git pull的問題是它把過程的細節都隱藏了起來，以至於你不用去了解git中各種類型分支的區別和使用方法。當然，多數時候這是沒問題的，但一旦代碼有問題，你很難找到出錯的地方。看起來git pull的用法會使你吃驚，簡單看一下git的使用文檔應該就能說服你。將下載（fetch）和合並（merge）放到一個命令裏的另外一個弊端是，你的本地工作目錄在未經確認的情況下就會被遠程分支更新。當然，除非你關閉所有的安全選項，否則git pull在你本地工作目錄還不至於造成不可挽回的損失，但很多時候我們寧願做的慢一些，也不願意返工重來。
1.分支(Branches)
在說git pull之前，我們需要先澄清分支的概念（branches）。很多人像寫代碼似的用一行話來描述分支是什麼，例如:
準確而言，分支的概念不是一條線，而類似於開發中的有向無環圖
分支類似於一個重量級的大對象集合。
我認爲你應該這樣來理解分支的概念：它是用來標記特定的代碼提交，每一個分支通過SHA1sum值來標識，所以對分支進行的操作是輕量級的–你改變的僅僅是SHA1sum值。
這個定義或許會有意想不到的影響。比如，假設你有兩個分支，“stable” 和 “new-idea”, 它們的頂端在版本 E 和 F:
A-----C----E ("stable")
\
B-----D-----F ("new-idea")所以提交(commits) A, C和 E 屬於“stable”，而 A, B, D 和 F 屬於 “new-idea”。如果之後你用下面的命令 將“new-idea” merge 到 “stable” ：
git checkout stable # Change to work on the branch "stable"
git merge new-idea # Merge in "new-idea"…那麼你會得到這個：
A-----C----E----G ("stable")
\ /
B-----D-----F ("new-idea")要是你繼續在“new idea” 和“stable”分支提交, 會得到：
A-----C----E----G---H ("stable")
\ /
B-----D-----F----I ("new-idea")因此現在A, B, C, D, E, F, G 和 H 屬於 “stable”，而A, B, D, F 和 I 屬於 “new-idea”。
當然了，分支確實有些特殊的屬性——其中最重要的是，如果你在一個分支進行作業並創建了一個新的提交(commits)，該分支的頂端將前進到那個提交(commits)。這正是你所希望的。當用git merge 進行合併(merge)的時候，你只是指定了要合併到當前分支的那個併入分支，以及當前分支的當前進展。
另一個表明使用分支會有很大幫助的觀點的常見情形是：假設你直接工作在一個項目的主要分支（稱爲“主版本”），當你意識到你所做的可能是一個壞主意時已經晚了，這時你肯定寧願自己是工作在一個主題分支上。如果提交圖看起來像這樣：
last version from another repository
|
v
M---N-----O----P---Q ("master")那麼你把你的工作用下面的一組命令分開做（如圖顯示的是執行它們之後所更改的狀態）：
git branch dubious-experiment
M---N-----O----P---Q ("master" and "dubious-experiment")
git checkout master
# Be careful with this next command: make sure "git status" is
# clean, you're definitely on "master" and the
# "dubious-experiment" branch has the commits you were working
# on first...
git reset --hard <SHA1sum of commit N>
("master")
M---N-------------O----P---Q ("dubious-experiment")
git pull # Or something that updates "master" from
# somewhere else...
M--N----R---S ("master")
\
O---P---Q ("dubious-experiment")2.分支類型
分支這個術語不太容易理解,而且在git的開發過程中發生了很多變化。但簡單來說git的分支只有兩種：
“本地分支(local branches)。
當你輸入“git branch”時顯示的。例如下面這個小例子：
$ git branch
debian
server
* master“遠程跟蹤分支(Remote-tracking branches)“。
當你輸入“git branch -r”是顯示的，如:
$ git branch -r
cognac/master
fruitfly/server
origin/albert
origin/ant
origin/contrib
origin/cross-compile從上面的輸出可以看到，跟蹤分支的名稱前有一個“遠程的”標記名稱（如 :origin, cognac, fruitfly）後面跟一個“／”，然後遠程倉庫裏分支的真正名稱。
（“遠程名稱”是一個代碼倉庫別名，和本地目錄或URL是一個含義，你可以通過”git remote”命令自由定義額外的“遠程名稱”。但“git clone”命令默認使用的是“origin”這個名稱。）
如果你對分支在本地是如何存儲感興趣的話，看看下面文件：
.git/refs/head/[本地分支]
.git/refs/remotes/[正在跟蹤的分支]兩種類型的分支在某些方面十分相似-它們都只是在本地存儲一個表示提交的SHA1校驗和。（我強調“本地”，因爲許多人看到”origin/master” 就認爲這個分支在某種意義上說是不完整的，沒有訪問遠端服務器的權限- 其實不是這種情況。）
不管如何相似，它們還是有一個特別重大的區別：
更改遠端跟蹤分支的安全方法是使用git fetch或者是作爲git-push副產品，你不能直接對遠端跟蹤分支這麼操作。相反，你總得切換到本地分支，然後創建可移動到分支頂端的新提交 。
因此，你對遠端跟蹤分支最多能做的是下面事情中的一件：
使用git fetch 更新遠端跟蹤分支
合併遠端跟蹤分支到當前分支
根據遠端跟蹤分支創建本地分支
3.基於遠程跟蹤分支創建本地分支
如果你想基於遠程跟蹤分支創建本地分支（在本地分支上工作）,你可以使用如下命令：git branch –track或git checkout –track -b，兩個命令都可以讓你切換到新創建的本地分支。例如你用git branch -r命令看到一個遠程跟蹤分支的名稱爲“origin/refactored”是你所需要的，你可以使用下面的命令：
git checkout --track -b refactored origin/refactored在上面的命令裏，“refactored”是這個新分支的名稱，“origin/refactored”則是現存遠程跟蹤分支的名稱。（在git最新的版本里，例子中‘-track’選項已經不需要了，如果最後一個參數是遠程跟蹤分支，這個參數會被默認加上。）
“–track”選項會設置一些變量，來保持本地分支和遠程跟蹤分支的相關性。他們對下面的情況很有用：
git pull命令下載新的遠程跟蹤分支之後，可以知道合併到哪個本地分支裏
使用git checkout檢查本地分支時，可以輸出一些有用的信息：
Your branch and the tracked remote branch 'origin/master'
have diverged, and respectively have 3 and 384 different
commit(s) each.或者：
Your branch is behind the tracked remote branch
'origin/master' by 3 commits, and can be fast-forwarded.允許使用的配置變量是：“branch..merge”和“branch..remote”，但通常情況下你不用考慮他們的設置。
從遠程代碼倉庫創建一個本地分支之後，你會注意到，“git branch -r”能列出很多遠程跟蹤分支，但你的電腦上只有一個本地分支，你需要給上面的命令設置一個參數，來指定本地分支和遠程分支的對應。
有一些術語上的說法容易混淆需要注意一下：“track”在當作參數”-track”使用時，意思指通過本地分支對應一個遠程跟蹤分支。在遠程跟蹤分支中則指遠程代碼倉庫中的跟蹤分支。有點繞口。。。
下面我們來看一個例子，如何從遠程分支中更新本地代碼，以及如何把本地分支推送到一個新的遠程倉庫中。
4.從遠端倉庫進行更新
如果我想從遠端的源倉庫更新到本地的代碼倉庫，可以輸入“git fetch origin”的命令，該命令的輸入類似如下格式：
remote: Counting objects: 382, done.
remote: Compressing objects: 100% (203/203), done.
remote: Total 278 (delta 177), reused 103 (delta 59)
Receiving objects: 100% (278/278), 4.89 MiB | 539 KiB/s, done.
Resolving deltas: 100% (177/177), completed with 40 local objects.
From ssh://[email protected]/srv/git/fiji
3036acc..9eb5e40 debian-release-20081030 -> origin/debian-release-20081030
* [new branch] debian-release-20081112 -> origin/debian-release-20081112
* [new branch] debian-release-20081112.1 -> origin/debian-release-20081112.1
3d619e7..6260626 master -> origin/master
```
最重要的是這兩行： 3036acc..9eb5e40 debian-release-20081030 -> origin/debian-release-20081030
[new branch] debian-release-20081112 -> origin/debian-release-20081112
第一行表明遠端的origin/debian-release-20081030分支的提交(commit)ID已經從3036acc更新爲9eb5e40。箭頭前的部分是遠端分支的名稱。
第二行是我們採取的動作，創建遠程跟蹤分支（如果遠程倉庫有新的tags，git fetch也會一併下載到本地）。
前面那些行顯示出“git fetch”命令會將哪些文件下載到本地，這些文件一旦下載到本地之後，就可以在本地進行任意操作了。
“git fetch”命令執行完畢之後，還不會立即將下載的文件合併到你當前工作目錄裏，這就給你了一個選擇下一步操作的機會，要是想將從遠程分支下載的文件更新到你的工作目錄裏，你需要執行一個“合併（merge）”操作。
例如，我當前的本地分支爲”master“（執行git checkout master後），這時我想執行合併操作：
git merge origin/master( 幾句題外話：合併的時候有可能你還沒有對遠程分支提交過任何的更改，或者可能是一個複雜的合併。)
如果你只是想看看本地分支和遠程分支的差異，你可以使用下面的命令：
git diff master origin/master單獨進行下載和合並是一個好的做法，你可以先看看下載的是什麼，然後再決定是否和本地代碼合併。而且分開來做，可以清晰的區別開本地分支和遠程分支，方便選擇使用。
5. 把你的變更推送到一個遠程倉庫
如何通過其他的方式呢? 假設你對 “experimental”分支做了變更並且希望把他push到”origin”遠程倉庫中去. 你可以這樣做:
git push origin experimental你可能將會收到:遠程倉庫無法fast-forward該分支的錯誤信息, 這將意味着可能有別人push了不同的變更到了這個分支上.所以,你需要fetch和merge別人的變更並再次嘗試push操作.