1、github官網註冊賬號，下載gitbash，完成基本配置，推薦開源中國上的一篇部落格：簡單使用Git和Github來管理自己的程式碼和讀書筆記
2、基礎階段常用操作：
知乎上關於git三個區解釋如下：

工作區(working diretory) 用於修改檔案 快取區(stage) 是用來暫時存放工作區中修改的內容 提交歷史（commit history） 提交程式碼的歷史記錄

下面詳細敘述一些命令
1、vim命令的使用
一、vim 有兩種工作模式：
1.命令模式：接受、執行 vim操作命令的模式，開啟檔案後的預設模式；
2.編輯模式：對開啟的檔案內容進行 增、刪、改 操作的模式；
3.在編輯模式下按下ESC鍵，回退到命令模式；在命令模式下按i，進入編輯模式
二、建立、開啟檔案：
1.輸入 touch 檔名 ，可建立檔案。
2.使用 vim 加檔案路徑（或檔名）的模式開啟檔案，如果檔案存在則開啟現有檔案，如果檔案不存在則新建檔案。
3.鍵盤輸入字母i進入插入編輯模式。
三、儲存檔案：
1.在編輯模式下編輯檔案
2.按下ESC鍵，退出編輯模式，切換到命令模式。
3.在命令模式下鍵入"ZZ"或者":wq"儲存修改並且退出 vim。
4.如果只想儲存檔案，則鍵入":w"，回車後底行會提示寫入操作結果，並保持停留在命令模式。
四、放棄所有檔案修改：
1.放棄所有檔案修改：按下ESC鍵進入命令模式，鍵入":q!“回車後放棄修改並退出vim。
2.放棄所有檔案修改，但不退出 vi，即回退到檔案開啟後最後一次儲存操作的狀態，繼續進行檔案操作：按下ESC鍵進入命令模式，鍵入”:e!"，回車後回到命令模式。
五、檢視檔案內容：
在git視窗，輸入命令：cat 檔名
六、建立資料夾
在git視窗，輸入命令：touch 資料夾名
2、git status

1、執行 $vim git2.txt
出現編輯頁面，按照vim的基本操作操作
執行 $git status
結果：
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   git.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   git2.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        git

2、執行 $git status -s
結果：
$ git status -s
M  git.txt（之前執行過的）
 M git2.txt
?? git
3、執行：
$git add git2.txt
$git status
結果：
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   git.txt
        modified:   git2.txt   //出現了

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        git
4、當全部add到暫存區後在執行git status -s
結果：//"AM" 狀態的意思是，這個檔案在我們將它新增到快取（暫存區）之後又有改動
A  git
M  git.txt
M  git2.txt

3、git diff
執行 git diff 來檢視執行 git status 的結果的詳細資訊。
git diff 命令顯示已寫入快取與已修改但尚未寫入快取的改動的區別。git diff 有兩個主要的應用場景。
尚未快取的改動：git diff
檢視已快取的改動： git diff --cached（add命令之後）
檢視已快取的與未快取的所有改動：git diff HEAD
顯示摘要而非整個 diff：git diff --stat
例項：

$ git diff --cached
diff --git a/git b/git
new file mode 100644
index 0000000..eac2252
--- /dev/null
+++ b/git
@@ -0,0 +1,2 @@
+<D6><B4><D0><D0><C1><CB><B2><E5><C8><EB><B2><D9><D7><F7>ZZ
+HELLO
diff --git a/git.txt b/git.txt
index 5255b58..e74700d 100644
--- a/git.txt
+++ b/git.txt
@@ -1 +1,2 @@
-<B3><CC><D0><F2>
\ No newline at end of file
+<B3><CC><D0><F2>
+git status testings
diff --git a/git2.txt b/git2.txt
index 5cfb0d7..d2deb43 100644
--- a/git2.txt
+++ b/git2.txt
@@ -1 +1,2 @@

4、git diff
git reset HEAD 命令用於取消已快取的內容
示例：

$ git status -s
M  git.txt
M  git2.txt
Administrator@965CKTUF3BYFX7F MINGW64 /e/Git/GitTest (master)
$ git reset HEAD -- git2.txt
Unstaged changes after reset:
M       git2.txt
Administrator@965CKTUF3BYFX7F MINGW64 /e/Git/GitTest (master)
$ git status -s
M  git.txt
 M git2.txt

5、git rm
如果只是簡單地從工作目錄中手工刪除檔案，執行 git status 時就會在 Changes not staged for commit 的提示。要從 Git 中移除某個檔案，就必須要從已跟蹤檔案清單中移除，然後提交。可以用以下命令完成此項工作git rm <file>
如果刪除之前修改過並且已經放到暫存區域的話，則必須要用強制刪除選項 git rm -f <file>
如果把檔案從暫存區域移除，但仍然希望保留在當前工作目錄中，換句話說，僅是從跟蹤清單中刪除，使用 --cached 選項即可git rm --cached <file>
如我們刪除 hello.php檔案：

    $ git rm hello.php 
    rm 'hello.php'
    $ ls
    README

不從工作區中刪除檔案：

    rm 'README'
    $ ls
    README

可以遞迴刪除，即如果後面跟的是一個目錄做為引數，則會遞迴刪除整個目錄中的所有子目錄和檔案：git rm –r *
進入某個目錄中，執行此語句，會刪除該目錄下的所有檔案和子目錄。git mv命令用於移動或重新命名一個檔案、目錄、軟連線。我們先把剛移除的 README 添加回來：$ git add README
然後對其重名:

   $ git mv README  README.md
   $ ls
   README.md

git常用命令表：

git branch 分支
以下內容摘自部落格 git branch 分支
Git 儲存的不是檔案的變化或者差異，而是一系列不同時刻的檔案快照。在進行提交操作時，Git 會儲存一個提交物件，該提交物件會包含一個指向暫存內容快照的指標。 但不僅僅是這樣，該提交物件還包含了作者的姓名和郵箱、提交時輸入的資訊以及指向它的父物件的指標。首次提交產生的提交物件沒有父物件，普通提交操作產生的提交物件有一個父物件，而由多個分支合併產生的提交物件有多個父物件。
Git 的分支，其實分支上僅僅是指向提交物件的可變指標。 Git的預設分支名字是 master ，在多次提交操作之後，你其實已經有一個指向最後那個提交物件的 master 分支。它會在每次的提交操作中自動向前移動。
注意： Git的 “master” 分支並不是一個特殊分支。它就跟其他分支完全沒有區別。之所以幾乎每一個倉庫都有 master 分支，是因為 git init 命令預設建立它，並且大多數人都懶得去改動它。
1、建立分支

git branch 分支名
例如：git branch gittest1
執行 $git log --oneline --decorate
結果：
$ git log --oneline --decorate
4674fac (HEAD -> master, gittest1) all reset
b5aecaa (origin/master) Third
f9ddd86 Second submit
aea39a3 first
192f45f Initial commit

對上述結果作如下圖形解釋：
執行過git branch gittest1後會在當前所在的提交物件上建立一個指標

那麼，Git 是如何知道當前在哪一個分支上呢？ 也很簡單，它有一個名為 HEAD 的特殊指標。 請注意它和許多其它版本控制系統（如 Subversion 或 CVS）裡的 HEAD 概念完全不同。 在 Git 中，它是一個指標，指向當前所在的本地分支（將 HEAD 想象為當前分支的別名）。 在本例中，你仍然在 master 分支上。 因為 git branch 命令僅僅建立一個新分支，並不會自動切換到新分支中去。

如上圖所示，當前 “master” 和 “testing” 分支均指向校驗和以 4674fac 開頭的提交物件
2、分支切換

執行 $git chechout 分支名
如：git checkout gittest1
結果為：
$ git checkout gittest1
Switched to branch 'gittest1'
M       test.txt

現在對gittest1分支進行操作

執行：$vim test.txt，對test.txt進行更改
接著執行：$git commit -a -m 'made a change'
結果：
$ git commit -a -m 'made a change'
[gittest1 6aee2ca] made a change
 1 file changed, 3 insertions(+)
 
再執行：$git log --oneline --decorate
結果為：
6aee2ca (HEAD -> gittest1) made a change
4674fac (master) all reset
b5aecaa (origin/master) Third
f9ddd86 Second submit
aea39a3 first
192f45f Initial commit
發現gittest1分支向右移動，而master分支沒動

如圖：

切換到master執行$git checkout master 這條命令做了兩件事。 一是使 HEAD 指回 master 分支，二是將工作目錄恢復成 master 分支所指向的快照內容。 也就是說，你現在做修改的話，專案將始於一個較舊的版本。 本質上來講，這就是忽略 gittest1 分支所做的修改，以便於向另一個方向進行開發。

注意：分支切換會改變你工作目錄中的檔案
在切換分支時，一定要注意你工作目錄裡的檔案會被改變。 如果是切換到一個較舊的分支，你的工作目錄會恢復到該分支最後一次提交時的樣子。 如果 Git 不能幹淨利落地完成這個任務，它將禁止切換分支。
下面在在master分支上做如下事情

執行 $vim git.txt
接著執行：$git commit -a -m 'make all chages'
結果為：
$ git commit -a -m 'make all changes'
[master ff42feb] make all changes
 1 file changed, 1 insertion(+)
 
接著執行檢視操作：
$ git log --oneline --decorate
ff42feb (HEAD -> master) make all changes//發現master也已經向右移動，具體結果如下圖所示
4674fac all reset
b5aecaa (origin/master) Third
f9ddd86 Second submit
aea39a3 first
192f45f Initial commit

如圖：

對於在gitbash上檢視分支的情況，可以執行如下操作

$ git log --oneline --decorate --graph --all

結果如下，與上圖一致。

$ git log --oneline --decorate --graph --all
* ff42feb (HEAD -> master) make all changes
| * 6aee2ca (gittest1) made a change
|/
* 4674fac all reset
* b5aecaa (origin/master) Third
* f9ddd86 Second submit
* aea39a3 first
* 192f45f Initial commit

**關於分支建立的一些敘述：**由於 Git 的分支實質上僅是包含所指物件校驗和（長度為 40 的 SHA-1 值字串）的檔案，所以它的建立和銷燬都異常高效。 建立一個新分支就像是往一個檔案中寫入 41 個位元組（40 個字元和 1 個換行符）。這與過去大多數版本控制系統形成了鮮明的對比，它們在建立分支時，將所有的專案檔案都複製一遍，並儲存到一個特定的目錄。 完成這樣繁瑣的過程通常需要好幾秒鐘，有時甚至需要好幾分鐘。所需時間的長短，完全取決於專案的規模。而在 Git 中，任何規模的專案都能在瞬間建立新分支。 同時，由於每次提交都會記錄父物件，所以尋找恰當的合併基礎（譯註：即共同祖先）也是同樣的簡單和高效。 這些高效的特性使得 Git 鼓勵開發人員頻繁地建立和使用分支。
建立分支的同時更換到此分支可執行 git checkout -b 分支名，如：git checkout -b test。
**注意：**當專案在某點出現問題時，就可以新建分支並切換到此分支上進行修復。當問題修復後，就需要將分支合併，下面介紹分支的合併
3、分支合併
分支合併，首先應該切換到 master 分支，但是，在切換之前，要留意你的工作目錄和暫存區裡那些還沒有被提交的修改，它可能會和你即將檢出的分支產生衝突從而阻止 Git 切換到該分支。 最好的方法是，在你切換分支之前，保持好一個乾淨的狀態。 有一些方法可以繞過這個問題（即，儲存進度（stashing） 和 修補提交（commit amending））。假設可以切換回 master 分支
執行:

$git checkout master

接著就可以合併分支了，執行

git merge 剛才用於修復bug的分支
如：git merge test

執行上述命令後 Git 會為你完成合並工作，Git 將此次合併的結果做一個新的快照並且自動建立一個新的提交指向它，一切就是這麼簡單。
4、遇到衝突時的分支合併
有時候合併操作並不會如此順利。如果你在兩個不同的分支中，對同一個檔案的同一個部分進行了不同的修改，Git 就沒法乾淨的合併它們。 如果你在對 某個 問題的修改和在 master 的修改都涉及到同一個檔案的同一處，在合併它們的時候就會產生合併衝突：

   $ git merge issue10
    Auto-merging index.html
    CONFLICT (content): Merge conflict in index.html
    Automatic merge failed; fix conflicts and then commit the result.

此時 Git 做了合併，但是沒有自動地建立一個新的合併提交。 Git 會暫停下來，等待你去解決合併產生的衝突。 你可以在合併衝突後的任意時刻使用 git status 命令來檢視那些因包含合併衝突而處於未合併（unmerged）狀態的檔案。
任何因包含合併衝突而有待解決的檔案，都會以未合併狀態標識出來。 Git 會在有衝突的檔案中加入標準的衝突解決標記，這樣你可以開啟這些包含衝突的檔案然後手動解決衝突。 出現衝突的檔案會包含一些特殊區段，看起來像下面這個樣子：

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> issue10:index.html

這表示 HEAD 所指示的版本（也就是你的 master 分支所在的位置，因為你在執行 merge 命令的時候已經檢出到了這個分支）在這個區段的上半部分（======= 的上半部分），而剛才問題的分支所指示的版本在 ======= 的下半部分。 為了解決衝突，你必須選擇使用由 ======= 分割的兩部分中的一個，或者你也可以自行合併這些內容。 例如，你可以通過把這段內容換成下面的樣子來解決衝突：

<div id="footer">
please contact us at email.support@github.com
</div>

上述的衝突解決方案僅保留了其中一個分支的修改，並且 <<<<<<< , ======= , 和 >>>>>>> 這些行被完全刪除了。 在你解決了所有檔案裡的衝突之後，對每個檔案使用 git add 命令來將其標記為衝突已解決。 一旦暫存這些原本有衝突的檔案，Git 就會將它們標記為衝突已解決。
你可以再次執行 git status 來確認所有的合併衝突都已被解決，如果你對結果感到滿意，並且確定之前有衝突的的檔案都已經暫存了，這時你可以輸入 git commit 來完成合並提交。
5、刪除分支
直接執行：git branch -d 分支名
6、分支管理
git branch 命令不只是可以建立與刪除分支。 如果不加任何引數執行它，會得到當前所有分支的一個列表：

$ git branch
  gittest1
* master

注意 master 分支前的 * 字元：它代表現在檢出的那一個分支（也就是說，當前 HEAD 指標所指向的分支）。 這意味著如果在這時候提交，master 分支將會隨著新的工作向前移動。 如果需要檢視每一個分支的最後一次提交，可以執行 git branch -v 命令：

$ git branch -v
  gittest1 6aee2ca made a change
* master   ff42feb make all changes

–merged 與 --no-merged 這兩個有用的選項可以過濾這個列表中已經合併或尚未合併到當前分支的分支

$ git branch --merged
* master

Administrator@965CKTUF3BYFX7F MINGW64 /e/Git/GitTest (master)
$ git branch --no-merged
  gittest1

當包含了還未合併的工作的分支，嘗試使用 git branch -d 命令刪除它時會失敗，如果真的想要刪除分支並丟掉那些工作，可以使用 -D 選項強制刪除它。
分支開發工作流
由於分支管理的便捷，因此衍生出一些典型的工作模式，可根據專案實際情況選擇使用。
1、長期分支
因為 Git 使用簡單的三方合併，所以就算在一段較長的時間內，反覆把一個分支合併入另一個分支，也不是什麼難事。 也就是說，在整個專案開發週期的不同階段，你可以同時擁有多個開放的分支；你可以定期地把某些特性分支合併入其他分支中。

許多使用 Git 的開發者都喜歡使用這種方式來工作，比如只在 master 分支上保留完全穩定的程式碼——有可能僅僅是已經發布或即將釋出的程式碼。 他們還有一些名為 develop 或者 next 的平行分支，被用來做後續開發或者測試穩定性——這些分支不必保持絕對穩定，但是一旦達到穩定狀態，它們就可以被合併入 master 分支了。 這樣，在確保這些已完成的特性分支（短期分支，比如之前的 issue10 分支）能夠通過所有測試，並且不會引入更多 bug 之後，就可以合併入主幹分支中，等待下一次的釋出。

一些大型專案還有一個 proposed（建議） 或 pu: proposed updates（建議更新）分支，它可能因包含一些不成熟的內容而不能進入 next 或者 master 分支。 這麼做的目的是使你的分支具有不同級別的穩定性；當它們具有一定程度的穩定性後，再把它們合併入具有更高級別穩定性的分支中。 再次強調一下，使用多個長期分支的方法並非必要，但是這麼做通常很有幫助，尤其是當你在一個非常龐大或者複雜的專案中工作時。
2、特性分支
特性分支對任何規模的專案都適用。 特性分支是一種短期分支，它被用來實現單一特性或其相關工作。 也許你從來沒有在其他的版本控制系統（VCS）上這麼做過，因為在那些版本控制系統中建立和合並分支通常很費勁。 然而，在 Git 中一天之內多次建立、使用、合併、刪除分支都很常見。

你在自己的特性分支（如 iss53 和 hotfix 分支）中提交了一些更新，並且在它們合併入主幹分支之後，你又刪除了它們。 這項技術能使你快速並且完整地進行上下文切換（context-switch）——因為你的工作被分散到不同的流水線中，在不同的流水線中每個分支都僅與其目標特性相關，因此，在做程式碼審查之類的工作的時候就能更加容易地看出你做了哪些改動。 你可以把做出的改動在特性分支中保留幾分鐘、幾天甚至幾個月，等它們成熟之後再合併，而不用在乎它們建立的順序或工作進度。

請牢記，當你做這麼多操作的時候，這些分支全部都存於本地。 當你新建和合並分支的時候，所有這一切都只發生在你本地的 Git 版本庫中 —— 沒有與伺服器發生互動。
3、遠端分支
遠端引用是對遠端倉庫的引用（指標），包括分支、標籤等等。 可通過 git ls-remote (remote) 來顯式地獲得遠端引用的完整列表，或者通過 git remote show (remote) 獲得遠端分支的更多資訊。 然而，一個更常見的做法是利用遠端跟蹤分支。

遠端跟蹤分支是遠端分支狀態的引用。 它們是你不能移動的本地引用，當你做任何網路通訊操作時，它們會自動移動。 遠端跟蹤分支像是你上次連線到遠端倉庫時，那些分支所處狀態的書籤。

它們以 (remote)/(branch) 形式命名。假設你的網路裡有一個在 git.ourcompany.com 的 Git 伺服器。 如果你從這裡克隆，Git 的 clone 命令會為你自動將其命名為 origin，拉取它的所有資料，建立一個指向它的 master 分支的指標，並且在本地將其命名為 origin/master。 Git 也會給你一個與 origin 的 master 分支在指向同一個地方的本地 master 分支，這樣你就有工作的基礎。
注意：“origin” 並無特殊含義
遠端倉庫名字 “origin” 與分支名字 “master” 一樣，在 Git 中並沒有任何特別的含義一樣。 同時 “master” 是當你執行 git init 時預設的起始分支名字，原因僅僅是它的廣泛使用，“origin” 是當你執行 git clone 時預設的遠端倉庫名字。 如果你執行 git clone -o booyah，那麼你預設的遠端分支名字將會是 booyah/master。
4、推送分支到遠端伺服器
當你想要公開分享一個分支時，需要將其推送到有寫入許可權的遠端倉庫上。 本地的分支並不會自動與遠端倉庫同步 - 你必須顯式地推送想要分享的分支。 這樣，你就可以把不願意分享的內容放到私人分支上，而將需要和別人協作的內容推送到公開分支。

如果希望和別人一起在名為 serverfix 的分支上工作，你可以像推送第一個分支那樣推送它。 執行 git push (remote) (branch):

$ git push origin serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit
 * [new branch]      serverfix -> serverfix

Git 自動將 serverfix 分支名字展開為 refs/heads/serverfix:refs/heads/serverfix，那意味著，“推送本地的 serverfix 分支來更新遠端倉庫上的 serverfix 分支。”

下一次其他協作者從伺服器上抓取資料時，他們會在本地生成一個遠端分支 origin/serverfix，指向伺服器的 serverfix 分支的引用：

$ git fetch origin
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/schacon/simplegit
 * [new branch]      serverfix    -> origin/serverfix

要特別注意的一點是當抓取到新的遠端跟蹤分支時，本地不會自動生成一份可編輯的副本（拷貝）。 換一句話說，這種情況下，不會有一個新的 serverfix 分支 - 只有一個不可以修改的 origin/serverfix 指標。
可以執行 git merge origin/serverfix 將這些工作合併到當前所在的分支。 如果想要在自己的 serverfix 分支上工作，可以將其建立在遠端跟蹤分支之上：

$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

這會給你一個用於工作的本地分支，並且起點位於 origin/serverfix。
5、跟蹤分支
從一個遠端跟蹤分支檢出一個本地分支會自動建立一個叫做 “跟蹤分支”（有時候也叫做 “上游分支”）。 跟蹤分支是與遠端分支有直接關係的本地分支。 如果在一個跟蹤分支上輸入 git pull，Git 能自動地識別去哪個伺服器上抓取、合併到哪個分支。

當克隆一個倉庫時，它通常會自動地建立一個跟蹤 origin/master 的 master 分支。 然而，如果你願意的話可以設定其他的跟蹤分支 - 其他遠端倉庫上的跟蹤分支，或者不跟蹤 master 分支。 可執行 git checkout -b [branch] [remotename]/[branch]。 這是一個十分常用的操作所以 Git 提供了 –track 快捷方式：

$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

將本地分支與遠端分支設定為不同名字:

$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'

現在，本地分支 sf 會自動從 origin/serverfix 拉取。

設定已有的本地分支跟蹤一個剛剛拉取下來的遠端分支，或者想要修改正在跟蹤的上游分支，你可以在任意時間使用 -u 或 –set-upstream-to 選項執行 git branch 來顯式地設定。

$ git branch -u origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.

檢視設定的所有跟蹤分支，可以使用 git branch 的 -vv 選項。 這會將所有的本地分支列出來並且包含更多的資訊，如每一個分支正在跟蹤哪個遠端分支與本地分支是否是領先、落後或是都有。

$ git branch -vv
  iss53     7e424c3 [origin/iss53: ahead 2] forgot the brackets
  master    1ae2a45 [origin/master] deploying index fix
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it
  testing   5ea463a trying something new

這裡可以看到 iss53 分支正在跟蹤 origin/iss53 並且 “ahead” 是 2，意味著本地有兩個提交還沒有推送到伺服器上。 也能看到 master 分支正在跟蹤 origin/master 分支並且是最新的。 接下來可以看到 serverfix 分支正在跟蹤 teamone 伺服器上的 server-fix-good 分支並且領先 2 落後 1，意味著伺服器上有一次提交還沒有合併入同時本地有三次提交還沒有推送。 最後看到 testing 分支並沒有跟蹤任何遠端分支。

需要重點注意的一點是這些數字的值來自於你從每個伺服器上最後一次抓取的資料。 這個命令並沒有連線伺服器，它只會告訴你關於本地快取的伺服器資料。 如果想要統計最新的領先與落後數字，需要在執行此命令前抓取所有的遠端倉庫。 可以像這樣做：$ git fetch –all; git branch -vv
6、拉取
當 git fetch 命令從伺服器上抓取本地沒有的資料時，它並不會修改工作目錄中的內容。 它只會獲取資料然後讓你自己合併。 然而，有一個命令叫作 git pull 在大多數情況下它的含義是一個 git fetch 緊接著一個 git merge 命令。 如果有一個像之前章節中演示的設定好的跟蹤分支，不管它是顯式地設定還是通過 clone 或 checkout 命令為你建立的，git pull 都會查詢當前分支所跟蹤的伺服器與分支，從伺服器上抓取資料然後嘗試合併入那個遠端分支。

由於 git pull 的魔法經常令人困惑所以通常單獨顯式地使用 fetch 與 merge 命令會更好一些。
7、刪除遠端分支
假設你已經通過遠端分支做完所有的工作了 - 也就是說你和你的協作者已經完成了一個特性並且將其合併到了遠端倉庫的 master 分支（或任何其他穩定程式碼分支）。 可以執行帶有 –delete 選項的 git push 命令來刪除一個遠端分支。 如果想要從伺服器上刪除 serverfix 分支，執行下面的命令：

  $ git push origin --delete serverfix 
  To https://github.com/schacon/simplegit 
  - [deleted] serverfix 

基本上這個命令做的只是從伺服器上移除這個指標。 Git 伺服器通常會保留資料一段時間直到垃圾回收執行，所以如果不小心刪除掉了，通常是很容易恢復的。

至此，你現在應該能自如地建立並切換至新分支、在不同分支之間切換以及合併本地分支，你現在應該也能通過推送你的分支至共享服務以分享它們、使用共享分支與他人協作。