3，版本控制git-多人協做

若是你想得到一份已經存在了的 Git 倉庫的拷貝，好比說，你想爲某個開源項目貢獻本身的一份力，這時就要用到 `git clone` 命令。 若是你對其它的 VCS 系統（好比說Subversion）很熟悉，請留心一下你所使用的命令是"clone"而不是"checkout"。 這是 Git 區別於其它版本控制系統的一個重要特性，Git 克隆的是該 Git 倉庫服務器上的幾乎全部數據，而不是僅僅複製完成你的工做所須要文件。當你執行 `git clone` 命令的時候，默認配置下遠程 Git 倉庫中的每個文件的每個版本都將被拉取下來。 事實上，若是你的服務器的磁盤壞掉了，你一般可使用任何一個克隆下來的用戶端來重建服務器上的倉庫（雖然可能會丟失某些服務器端的掛鉤設置，可是全部版本的數據仍在）。

克隆倉庫的命令格式是 git clone [url] 。 好比，要克隆 Git 的可連接庫 libgit2，能夠用下面的命令：

$ git clone https://github.com/libgit2/libgit2

這會在當前目錄下建立一個名爲 「libgit2」 的目錄，並在這個目錄下初始化一個 .git 文件夾，從遠程倉庫拉取下全部數據放入 .git 文件夾，而後從中讀取最新版本的文件的拷貝。 若是你進入到這個新建的 libgit2 文件夾，你會發現全部的項目文件已經在裏面了，準備就緒等待後續的開發和使用。 若是你想在克隆遠程倉庫的時候，自定義本地倉庫的名字，你可使用以下命令：

$ git clone https://github.com/libgit2/libgit2 mylibgit

這將執行與上一個命令相同的操做，不過在本地建立的倉庫名字變爲 mylibgit。

Git 支持多種數據傳輸協議。 上面的例子使用的是 https:// 協議，不過你也可使用 git:// 協議或者使用 SSH 傳輸協議，好比 user@server:path/to/repo.git .

在上一節咱們看到了，多人在同一個分支上協做時，很容易出現衝突。即便沒有衝突，後push的童鞋不得不先pull，在本地合併，而後才能push成功。

每次合併再push後，分支變成了這樣：

$ git log --graph --pretty=oneline --abbrev-commit
* d1be385 (HEAD -> master, origin/master) init hello
*   e5e69f1 Merge branch 'dev'
|\  
| *   57c53ab (origin/dev, dev) fix env conflict
| |\  
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
| |/  
* |   12a631b merged bug fix 101
|\ \  
| * | 4c805e2 fix bug 101
|/ /  
* |   e1e9c68 merge with no-ff
|\ \  
| |/  
| * f52c633 add merge
|/  
*   cf810e4 conflict fixed

總之看上去很亂，有強迫症的童鞋會問：爲何Git的提交歷史不能是一條幹淨的直線？

實際上是能夠作到的！

Git有一種稱爲rebase的操做，有人把它翻譯成「變基」。

先不要隨意展開想象。咱們仍是從實際問題出發，看看怎麼把分叉的提交變成直線。

在和遠程分支同步後，咱們對hello.py這個文件作了兩次提交。用git log命令看看：

$ git log --graph --pretty=oneline --abbrev-commit
* 582d922 (HEAD -> master) add author
* 8875536 add comment
* d1be385 (origin/master) init hello
*   e5e69f1 Merge branch 'dev'
|\  
| *   57c53ab (origin/dev, dev) fix env conflict
| |\  
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
...

注意到Git用(HEAD -> master)和(origin/master)標識出當前分支的HEAD和遠程origin的位置分別是582d922 add author和d1be385 init hello，本地分支比遠程分支快兩個提交。

如今咱們嘗試推送本地分支：

$ git push origin master
To github.com:michaelliao/learngit.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

很不幸，失敗了，這說明有人先於咱們推送了遠程分支。按照經驗，先pull一下：

$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:michaelliao/learngit
   d1be385..f005ed4  master     -> origin/master
 * [new tag]         v1.0       -> v1.0
Auto-merging hello.py
Merge made by the 'recursive' strategy.
 hello.py | 1 +
 1 file changed, 1 insertion(+)

再用git status看看狀態：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 3 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

加上剛纔合併的提交，如今咱們本地分支比遠程分支超前3個提交。

用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit
*   e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit
|\  
| * f005ed4 (origin/master) set exit=1
* | 582d922 add author
* | 8875536 add comment
|/  
* d1be385 init hello
...

對強迫症童鞋來講，如今事情有點不對頭，提交歷史分叉了。若是如今把本地分支push到遠程，有沒有問題？

有！

什麼問題？

很差看！

有沒有解決方法？

有！

這個時候，rebase就派上了用場。咱們輸入命令git rebase試試：

$ git rebase
First, rewinding head to replay your work on top of it...
Applying: add comment
Using index info to reconstruct a base tree...
M    hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py
Applying: add author
Using index info to reconstruct a base tree...
M    hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py

輸出了一大堆操做，究竟是啥效果？再用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master) add author
* 3611cfe add comment
* f005ed4 (origin/master) set exit=1
* d1be385 init hello
...

本來分叉的提交如今變成一條直線了！這種神奇的操做是怎麼實現的？其實原理很是簡單。咱們注意觀察，發現Git把咱們本地的提交「挪動」了位置，放到了f005ed4 (origin/master) set exit=1以後，這樣，整個提交歷史就成了一條直線。rebase操做先後，最終的提交內容是一致的，可是，咱們本地的commit修改內容已經變化了，它們的修改再也不基於d1be385 init hello，而是基於f005ed4 (origin/master) set exit=1，但最後的提交7e61ed4內容是一致的。

這就是rebase操做的特色：把分叉的提交歷史「整理」成一條直線，看上去更直觀。缺點是本地的分叉提交已經被修改過了。

最後，經過push操做把本地分支推送到遠程：

Mac:~/learngit michael$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To github.com:michaelliao/learngit.git
   f005ed4..7e61ed4  master -> master

再用git log看看效果：

$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master, origin/master) add author
* 3611cfe add comment
* f005ed4 set exit=1
* d1be385 init hello
...

遠程分支的提交歷史也是一條直線。

遠程分支

遠程引用是對遠程倉庫的引用（指針），包括分支、標籤等等。 你能夠經過 git ls-remote (remote) 來顯式地得到遠程引用的完整列表，或者經過 git remote show (remote) 得到遠程分支的更多信息。 然而，一個更常見的作法是利用遠程跟蹤分支。

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

它們以 (remote)/(branch) 形式命名。 例如，若是你想要看你最後一次與遠程倉庫 origin 通訊時 master分支的狀態，你能夠查看 origin/master 分支。 你與同事合做解決一個問題而且他們推送了一個 iss53 分支，你可能有本身的本地 iss53 分支；可是在服務器上的分支會指向 origin/iss53 的提交。

這可能有一點兒難以理解，讓咱們來看一個例子。 假設你的網絡裏有一個在 git.ourcompany.com 的 Git 服務器。 若是你從這裏克隆，Git 的 clone 命令會爲你自動將其命名爲 origin，拉取它的全部數據，建立一個指向它的 master 分支的指針，而且在本地將其命名爲 origin/master。 Git 也會給你一個與 origin 的 master 分支在指向同一個地方的本地 master 分支，這樣你就有工做的基礎。

Note	「origin」 並沒有特殊含義遠程倉庫名字 「origin」 與分支名字 「master」 同樣，在 Git 中並無任何特別的含義同樣。 同時 「master」 是當你運行 git init 時默認的起始分支名字，緣由僅僅是它的普遍使用，「origin」 是當你運行 git clone 時默認的遠程倉庫名字。 若是你運行 git clone -o booyah，那麼你默認的遠程分支名字將會是 booyah/master。

 

推送

當你想要公開分享一個分支時，須要將其推送到有寫入權限的遠程倉庫上。 本地的分支並不會自動與遠程倉庫同步 - 你必須顯式地推送想要分享的分支。 這樣，你就能夠把不肯意分享的內容放到私人分支上，而將須要和別人協做的內容推送到公開分支。

若是但願和別人一塊兒在名爲 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 分支。」 咱們將會詳細學習 refs/heads/ 部分，可是如今能夠先把它放在兒。 你也能夠運行 git push origin serverfix:serverfix，它會作一樣的事 - 至關於它說，「推送本地的 serverfix 分支，將其做爲遠程倉庫的 serverfix 分支」 能夠經過這種格式來推送本地分支到一個命名不相同的遠程分支。 若是並不想讓遠程倉庫上的分支叫作 serverfix，能夠運行 git push origin serverfix:awesomebranch 來將本地的 serverfix 分支推送到遠程倉庫上的 awesomebranch 分支。

下一次其餘協做者從服務器上抓取數據時，他們會在本地生成一個遠程分支 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。

跟蹤分支

從一個遠程跟蹤分支檢出一個本地分支會自動建立一個叫作 「跟蹤分支」（有時候也叫作 「上游分支」）。 跟蹤分支是與遠程分支有直接關係的本地分支。 若是在一個跟蹤分支上輸入 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.

Note	上游快捷方式當設置好跟蹤分支後，能夠經過 @{upstream} 或 @{u} 快捷方式來引用它。 因此在 master 分支時而且它正在跟蹤 origin/master 時，若是願意的話可使用 git merge @{u}來取代 git merge origin/master。

若是想要查看設置的全部跟蹤分支，可使用 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 分支而且領先 3 落後 1，意味着服務器上有一次提交尚未合併入同時本地有三次提交尚未推送。 最後看到 testing 分支並無跟蹤任何遠程分支。

須要重點注意的一點是這些數字的值來自於你從每一個服務器上最後一次抓取的數據。 這個命令並無鏈接服務器，它只會告訴你關於本地緩存的服務器數據。 若是想要統計最新的領先與落後數字，須要在運行此命令前抓取全部的遠程倉庫。 能夠像這樣作：$ git fetch --all; git branch -vv

拉取

當 git fetch 命令從服務器上抓取本地沒有的數據時，它並不會修改工做目錄中的內容。 它只會獲取數據而後讓你本身合併。 然而，有一個命令叫做 git pull 在大多數狀況下它的含義是一個 git fetch緊接着一個 git merge 命令。 若是有一個像以前章節中演示的設置好的跟蹤分支，無論它是顯式地設置仍是經過 clone或 checkout 命令爲你建立的，git pull 都會查找當前分支所跟蹤的服務器與分支，從服務器上抓取數據而後嘗試合併入那個遠程分支。

因爲 git pull 的魔法常常使人困惑因此一般單獨顯式地使用 fetch 與 merge 命令會更好一些。

刪除遠程分支

假設你已經經過遠程分支作完全部的工做了 - 也就是說你和你的協做者已經完成了一個特性而且將其合併到了遠程倉庫的 master 分支（或任何其餘穩定代碼分支）。 能夠運行帶有 --delete 選項的 git push 命令來刪除一個遠程分支。 若是想要從服務器上刪除 serverfix 分支，運行下面的命令：

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

基本上這個命令作的只是從服務器上移除這個指針。 Git 服務器一般會保留數據一段時間直到垃圾回收運行，因此若是不當心刪除掉了，一般是很容易恢復的。