廖雪峯Git教程2

時間 2019-11-06

標籤雪峯 git 教程欄目 Git 简体版

原文原文鏈接

轉自：https://www.liaoxuefeng.com/wiki/896043488029600

【遠程倉庫】

到目前爲止，咱們已經掌握瞭如何在Git倉庫裏對一個文件進行時光穿梭，你不再用擔憂文件備份或者丟失的問題了。javascript

但是有用過集中式版本控制系統SVN的童鞋會站出來講，這些功能在SVN裏早就有了，沒看出Git有什麼特別的地方。php

沒錯，若是隻是在一個倉庫裏管理文件歷史，Git和SVN真沒啥區別。爲了保證你如今所學的Git物超所值，未來絕對不會後悔，同時爲了打擊已經不幸學了SVN的童鞋，本章開始介紹Git的殺手級功能之一（注意是之一，也就是後面還有之二，之三……）：遠程倉庫。java

Git是分佈式版本控制系統，同一個Git倉庫，能夠分佈到不一樣的機器上。怎麼分佈呢？最先，確定只有一臺機器有一個原始版本庫，此後，別的機器能夠「克隆」這個原始版本庫，並且每臺機器的版本庫其實都是同樣的，並無主次之分。git

你確定會想，至少須要兩臺機器才能玩遠程庫不是？可是我只有一臺電腦，怎麼玩？github

其實一臺電腦上也是能夠克隆多個版本庫的，只要不在同一個目錄下。不過，現實生活中是不會有人這麼傻的在一臺電腦上搞幾個遠程庫玩，由於一臺電腦上搞幾個遠程庫徹底沒有意義，並且硬盤掛了會致使全部庫都掛掉，因此我也不告訴你在一臺電腦上怎麼克隆多個倉庫。sql

實際狀況每每是這樣，找一臺電腦充當服務器的角色，天天24小時開機，其餘每一個人都從這個「服務器」倉庫克隆一份到本身的電腦上，而且各自把各自的提交推送到服務器倉庫裏，也從服務器倉庫中拉取別人的提交。安全

徹底能夠本身搭建一臺運行Git的服務器，不過現階段，爲了學Git先搭個服務器絕對是小題大做。好在這個世界上有個叫GitHub的神奇的網站，從名字就能夠看出，這個網站就是提供Git倉庫託管服務的，因此，只要註冊一個GitHub帳號，就能夠免費得到Git遠程倉庫。ruby

在繼續閱讀後續內容前，請自行註冊GitHub帳號。因爲你的本地Git倉庫和GitHub倉庫之間的傳輸是經過SSH加密的，因此，須要一點設置：服務器

第1步：建立SSH Key。在用戶主目錄下，看看有沒有.ssh目錄，若是有，再看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個文件，若是已經有了，可直接跳到下一步。若是沒有，打開Shell（Windows下打開Git Bash），建立SSH Key：網絡

$ ssh-keygen -t rsa -C "youremail@example.com"

你須要把郵件地址換成你本身的郵件地址，而後一路回車，使用默認值便可，因爲這個Key也不是用於軍事目的，因此也無需設置密碼。

若是一切順利的話，能夠在用戶主目錄裏找到.ssh目錄，裏面有id_rsa和id_rsa.pub兩個文件，這兩個就是SSH Key的祕鑰對，id_rsa是私鑰，不能泄露出去，id_rsa.pub是公鑰，能夠放心地告訴任何人。

第2步：登錄GitHub，打開「Account settings」，「SSH Keys」頁面：

而後，點「Add SSH Key」，填上任意Title，在Key文本框裏粘貼id_rsa.pub文件的內容：

點「Add Key」，你就應該看到已經添加的Key：

爲何GitHub須要SSH Key呢？由於GitHub須要識別出你推送的提交確實是你推送的，而不是別人冒充的，而Git支持SSH協議，因此，GitHub只要知道了你的公鑰，就能夠確認只有你本身才能推送。

固然，GitHub容許你添加多個Key。假定你有若干電腦，你一下子在公司提交，一下子在家裏提交，只要把每臺電腦的Key都添加到GitHub，就能夠在每臺電腦上往GitHub推送了。

最後友情提示，在GitHub上免費託管的Git倉庫，任何人均可以看到喔（但只有你本身才能改）。因此，不要把敏感信息放進去。

若是你不想讓別人看到Git庫，有兩個辦法，一個是交點保護費，讓GitHub把公開的倉庫變成私有的，這樣別人就看不見了（不可讀更不可寫）。另外一個辦法是本身動手，搭一個Git服務器，由於是你本身的Git服務器，因此別人也是看不見的。這個方法咱們後面會講到的，至關簡單，公司內部開發必備。

確保你擁有一個GitHub帳號後，咱們就即將開始遠程倉庫的學習。

【添加遠程庫】

如今的情景是，你已經在本地建立了一個Git倉庫後，又想在GitHub建立一個Git倉庫，而且讓這兩個倉庫進行遠程同步，這樣，GitHub上的倉庫既能夠做爲備份，又可讓其餘人經過該倉庫來協做，真是一舉多得。

首先，登錄GitHub，而後，在右上角找到「Create a new repo」按鈕，建立一個新的倉庫：

在Repository name填入learngit，其餘保持默認設置，點擊「Create repository」按鈕，就成功地建立了一個新的Git倉庫：

目前，在GitHub上的這個learngit倉庫仍是空的，GitHub告訴咱們，能夠從這個倉庫克隆出新的倉庫，也能夠把一個已有的本地倉庫與之關聯，而後，把本地倉庫的內容推送到GitHub倉庫。

如今，咱們根據GitHub的提示，在本地的learngit倉庫下運行命令：

$ git remote add origin git@github.com:michaelliao/learngit.git

請千萬注意，把上面的michaelliao替換成你本身的GitHub帳戶名，不然，你在本地關聯的就是個人遠程庫，關聯沒有問題，可是你之後推送是推不上去的，由於你的SSH Key公鑰不在個人帳戶列表中。

添加後，遠程庫的名字就是origin，這是Git默認的叫法，也能夠改爲別的，可是origin這個名字一看就知道是遠程庫。

下一步，就能夠把本地庫的全部內容推送到遠程庫上：

$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

把本地庫的內容推送到遠程，用git push命令，其實是把當前分支master推送到遠程。

因爲遠程庫是空的，咱們第一次推送master分支時，加上了-u參數，Git不但會把本地的master分支內容推送的遠程新的master分支，還會把本地的master分支和遠程的master分支關聯起來，在之後的推送或者拉取時就能夠簡化命令。

推送成功後，能夠馬上在GitHub頁面中看到遠程庫的內容已經和本地如出一轍：

從如今起，只要本地做了提交，就能夠經過命令：

$ git push origin master

把本地master分支的最新修改推送至GitHub，如今，你就擁有了真正的分佈式版本庫！

SSH警告

當你第一次使用Git的clone或者push命令鏈接GitHub時，會獲得一個警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

這是由於Git使用SSH鏈接，而SSH鏈接在第一次驗證GitHub服務器的Key時，須要你確認GitHub的Key的指紋信息是否真的來自GitHub的服務器，輸入yes回車便可。

Git會輸出一個警告，告訴你已經把GitHub的Key添加到本機的一個信任列表裏了：

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.

這個警告只會出現一次，後面的操做就不會有任何警告了。

若是你實在擔憂有人冒充GitHub服務器，輸入yes前能夠對照GitHub的RSA Key的指紋信息是否與SSH鏈接給出的一致。

小結

要關聯一個遠程庫，使用命令git remote add origin git@server-name:path/repo-name.git；

關聯後，使用命令git push -u origin master第一次推送master分支的全部內容；

此後，每次本地提交後，只要有必要，就可使用命令git push origin master推送最新修改；

分佈式版本系統的最大好處之一是在本地工做徹底不須要考慮遠程庫的存在，也就是有沒有聯網均可以正常工做，而SVN在沒有聯網的時候是拒絕幹活的！當有網絡的時候，再把本地提交推送一下就完成了同步，真是太方便了！

【從遠程庫克隆】

上次咱們講了先有本地庫，後有遠程庫的時候，如何關聯遠程庫。

如今，假設咱們從零開發，那麼最好的方式是先建立遠程庫，而後，從遠程庫克隆。

首先，登錄GitHub，建立一個新的倉庫，名字叫gitskills：

咱們勾選Initialize this repository with a README，這樣GitHub會自動爲咱們建立一個README.md文件。建立完畢後，能夠看到README.md文件：

如今，遠程庫已經準備好了，下一步是用命令git clone克隆一個本地庫：

$ git clone git@github.com:michaelliao/gitskills.git Cloning into 'gitskills'... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3 Receiving objects: 100% (3/3), done.

注意把Git庫的地址換成你本身的，而後進入gitskills目錄看看，已經有README.md文件了：

$ cd gitskills $ ls README.md

若是有多我的協做開發，那麼每一個人各自從遠程克隆一份就能夠了。

你也許還注意到，GitHub給出的地址不止一個，還能夠用https://github.com/michaelliao/gitskills.git這樣的地址。實際上，Git支持多種協議，默認的git://使用ssh，但也可使用https等其餘協議。

使用https除了速度慢之外，還有個最大的麻煩是每次推送都必須輸入口令，可是在某些只開放http端口的公司內部就沒法使用ssh協議而只能用https。

小結

要克隆一個倉庫，首先必須知道倉庫的地址，而後使用git clone命令克隆。

Git支持多種協議，包括https，但經過ssh支持的原生git協議速度最快。

【分支管理】

分支就是科幻電影裏面的平行宇宙，當你正在電腦前努力學習Git的時候，另外一個你正在另外一個平行宇宙裏努力學習SVN。

若是兩個平行宇宙互不干擾，那對如今的你也沒啥影響。不過，在某個時間點，兩個平行宇宙合併了，結果，你既學會了Git又學會了SVN！

分支在實際中有什麼用呢？假設你準備開發一個新功能，可是須要兩週才能完成，第一週你寫了50%的代碼，若是馬上提交，因爲代碼還沒寫完，不完整的代碼庫會致使別人不能幹活了。若是等代碼所有寫完再一次提交，又存在丟失天天進度的巨大風險。

如今有了分支，就不用怕了。你建立了一個屬於你本身的分支，別人看不到，還繼續在原來的分支上正常工做，而你在本身的分支上幹活，想提交就提交，直到開發完畢後，再一次性合併到原來的分支上，這樣，既安全，又不影響別人工做。

其餘版本控制系統如SVN等都有分支管理，可是用過以後你會發現，這些版本控制系統建立和切換分支比蝸牛還慢，簡直讓人沒法忍受，結果分支功能成了擺設，你們都不去用。

但Git的分支是不同凡響的，不管建立、切換和刪除分支，Git在1秒鐘以內就能完成！不管你的版本庫是1個文件仍是1萬個文件。

【建立與合併分支】

在版本回退裏，你已經知道，每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git裏，這個分支叫主分支，即master分支。HEAD嚴格來講不是指向提交，而是指向master，master纔是指向提交的，因此，HEAD指向的就是當前分支。

一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能肯定當前分支，以及當前分支的提交點：

每次提交，master分支都會向前移動一步，這樣，隨着你不斷提交，master分支的線也愈來愈長。

當咱們建立新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當前分支在dev上：

你看，Git建立一個分支很快，由於除了增長一個dev指針，改改HEAD的指向，工做區的文件都沒有任何變化！

不過，從如今開始，對工做區的修改和提交就是針對dev分支了，好比新提交一次後，dev指針往前移動一步，而master指針不變：

假如咱們在dev上的工做完成了，就能夠把dev合併到master上。Git怎麼合併呢？最簡單的方法，就是直接把master指向dev的當前提交，就完成了合併：

因此Git合併分支也很快！就改改指針，工做區內容也不變！

合併完分支後，甚至能夠刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉後，咱們就剩下了一條master分支：

真是太神奇了，你看得出來有些提交是經過分支完成的嗎？

下面開始實戰。

首先，咱們建立dev分支，而後切換到dev分支：

$ git checkout -b dev Switched to a new branch 'dev'

git checkout命令加上-b參數表示建立並切換，至關於如下兩條命令：

$ git branch dev $ git checkout dev Switched to branch 'dev'

而後，用git branch命令查看當前分支：

$ git branch * dev master

git branch命令會列出全部分支，當前分支前面會標一個*號。

而後，咱們就能夠在dev分支上正常提交，好比對readme.txt作個修改，加上一行：

Creating a new branch is quick.

而後提交：

$ git add readme.txt $ git commit -m "branch test" [dev b17d20e] branch test 1 file changed, 1 insertion(+)

如今，dev分支的工做完成，咱們就能夠切換回master分支：

$ git checkout master Switched to branch 'master'

切換回master分支後，再查看一個readme.txt文件，剛纔添加的內容不見了！由於那個提交是在dev分支上，而master分支此刻的提交點並無變：

如今，咱們把dev分支的工做成果合併到master分支上：

$ git merge dev Updating d46f35e..b17d20e Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)

git merge命令用於合併指定分支到當前分支。合併後，再查看readme.txt的內容，就能夠看到，和dev分支的最新提交是徹底同樣的。

注意到上面的Fast-forward信息，Git告訴咱們，此次合併是「快進模式」，也就是直接把master指向dev的當前提交，因此合併速度很是快。

固然，也不是每次合併都能Fast-forward，咱們後面會講其餘方式的合併。

合併完成後，就能夠放心地刪除dev分支了：

$ git branch -d dev Deleted branch dev (was b17d20e).

刪除後，查看branch，就只剩下master分支了：

$ git branch * master

由於建立、合併和刪除分支很是快，因此Git鼓勵你使用分支完成某個任務，合併後再刪掉分支，這和直接在master分支上工做效果是同樣的，但過程更安全。

switch

咱們注意到切換分支使用git checkout <branch>，而前面講過的撤銷修改則是git checkout -- <file>，同一個命令，有兩種做用，確實有點使人迷惑。

實際上，切換分支這個動做，用switch更科學。所以，最新版本的Git提供了新的git switch命令來切換分支：

建立並切換到新的dev分支，可使用：

$ git switch -c dev

直接切換到已有的master分支，可使用：

$ git switch master

使用新的git switch命令，比git checkout要更容易理解。

小結

Git鼓勵大量使用分支：

查看分支：git branch

建立分支：git branch <name>

切換分支：git checkout <name>或者git switch <name>

建立+切換分支：git checkout -b <name>或者git switch -c <name>

合併某分支到當前分支：git merge <name>

刪除分支：git branch -d <name>

【解決衝突】

人生不如意之事十之八九，合併分支每每也不是一路順風的。

準備新的feature1分支，繼續咱們的新分支開發：

$ git checkout -b feature1 Switched to a new branch 'feature1'

修改readme.txt最後一行，改成：

Creating a new branch is quick AND simple.

在feature1分支上提交：

$ git add readme.txt

$ git commit -m "AND simple" [feature1 14096d0] AND simple 1 file changed, 1 insertion(+), 1 deletion(-)

切換到master分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits)

Git還會自動提示咱們當前master分支比遠程的master分支要超前1個提交。

在master分支上把readme.txt文件的最後一行改成：

Creating a new branch is quick & simple.

提交：

$ git add readme.txt $ git commit -m "& simple" [master 5dc6824] & simple 1 file changed, 1 insertion(+), 1 deletion(-)

如今，master分支和feature1分支各自都分別有新的提交，變成了這樣：

這種狀況下，Git沒法執行「快速合併」，只能試圖把各自的修改合併起來，但這種合併就可能會有衝突，咱們試試看：

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

果真衝突了！Git告訴咱們，readme.txt文件存在衝突，必須手動解決衝突後再提交。git status也能夠告訴咱們衝突的文件：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")

咱們能夠直接查看readme.txt的內容：

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD Creating a new branch is quick & simple. ======= Creating a new branch is quick AND simple. >>>>>>> feature1

Git用<<<<<<<，=======，>>>>>>>標記出不一樣分支的內容，咱們修改以下後保存：

Creating a new branch is quick and simple.

再提交：

$ git add readme.txt $ git commit -m "conflict fixed" [master cf810e4] conflict fixed

如今，master分支和feature1分支變成了下圖所示：

用帶參數的git log也能夠看到分支的合併狀況：

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple * | 5dc6824 & simple |/ * b17d20e branch test * d46f35e (origin/master) remove test.txt * b84166e add test.txt * 519219b git tracks changes * e43a48b understand how stage works * 1094adb append GPL * e475afc add distributed * eaadf4e wrote a readme file

最後，刪除feature1分支：

$ git branch -d feature1 Deleted branch feature1 (was 14096d0).

工做完成。

小結

當Git沒法自動合併分支時，就必須首先解決衝突。解決衝突後，再提交，合併完成。

解決衝突就是把Git合併失敗的文件手動編輯爲咱們但願的內容，再提交。

用git log --graph命令能夠看到分支合併圖。

【分支管理策略】

一般，合併分支時，若是可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。

若是要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就能夠看出分支信息。

下面咱們實戰一下--no-ff方式的git merge：

首先，仍然建立並切換dev分支：

$ git checkout -b dev Switched to a new branch 'dev'

修改readme.txt文件，並提交一個新的commit：

$ git add readme.txt 
$ git commit -m "add merge" [dev f52c633] add merge 1 file changed, 1 insertion(+)

如今，咱們切換回master：

$ git checkout master Switched to branch 'master'

準備合併dev分支，請注意--no-ff參數，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+)

由於本次合併要建立一個新的commit，因此加上-m參數，把commit描述寫進去。

合併後，咱們用git log看看分支歷史：

$ git log --graph --pretty=oneline --abbrev-commit * e1e9c68 (HEAD -> master) merge with no-ff |\ | * f52c633 (dev) add merge |/ * cf810e4 conflict fixed ...

能夠看到，不使用Fast forward模式，merge後就像這樣：

分支策略

在實際開發中，咱們應該按照幾個基本原則進行分支管理：

首先，master分支應該是很是穩定的，也就是僅用來發布新版本，平時不能在上面幹活；

那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，好比1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本；

你和你的小夥伴們每一個人都在dev分支上幹活，每一個人都有本身的分支，時不時地往dev分支上合併就能夠了。

因此，團隊合做的分支看起來就像這樣：

小結

Git分支十分強大，在團隊開發中應該充分應用。

合併分支時，加上--no-ff參數就能夠用普通模式合併，合併後的歷史有分支，能看出來曾經作過合併，而fast forward合併就看不出來曾經作過合併。

【Bug分支】

軟件開發中，bug就像屢見不鮮同樣。有了bug就須要修復，在Git中，因爲分支是如此的強大，因此，每一個bug均可以經過一個新的臨時分支來修復，修復後，合併分支，而後將臨時分支刪除。

當你接到一個修復一個代號101的bug的任務時，很天然地，你想建立一個分支issue-101來修復它，可是，等等，當前正在dev上進行的工做尚未提交：

$ git status
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) new file: hello.py 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: readme.txt

並非你不想提交，而是工做只進行到一半，還無法提交，預計完成還需1天時間。可是，必須在兩個小時內修復該bug，怎麼辦？

幸虧，Git還提供了一個stash功能，能夠把當前工做現場「儲藏」起來，等之後恢復現場後繼續工做：

$ git stash Saved working directory and index state WIP on dev: f52c633 add merge

如今，用git status查看工做區，就是乾淨的（除非有沒有被Git管理的文件），所以能夠放心地建立分支來修復bug。

首先肯定要在哪一個分支上修復bug，假定須要在master分支上修復，就從master建立臨時分支：

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) $ git checkout -b issue-101 Switched to a new branch 'issue-101'

如今修復bug，須要把「Git is free software ...」改成「Git is a free software ...」，而後提交：

$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 4c805e2] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)

修復完成後，切換到master分支，並完成合並，最後刪除issue-101分支：

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

太棒了，原計劃兩個小時的bug修復只花了5分鐘！如今，是時候接着回到dev分支幹活了！

$ git checkout dev Switched to branch 'dev' $ git status On branch dev nothing to commit, working tree clean

工做區是乾淨的，剛纔的工做現場存到哪去了？用git stash list命令看看：

$ git stash list stash@{0}: WIP on dev: f52c633 add merge

工做現場還在，Git把stash內容存在某個地方了，可是須要恢復一下，有兩個辦法：

一是用git stash apply恢復，可是恢復後，stash內容並不刪除，你須要用git stash drop來刪除；

另外一種方式是用git stash pop，恢復的同時把stash內容也刪了：

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) new file: hello.py 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: readme.txt Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

再用git stash list查看，就看不到任何stash內容了：

$ git stash list

你能夠屢次stash，恢復的時候，先用git stash list查看，而後恢復指定的stash，用命令：

$ git stash apply stash@{0}

在master分支上修復了bug後，咱們要想想，dev分支是早期從master分支分出來的，因此，這個bug其實在當前dev分支上也存在。

那怎麼在dev分支上修復一樣的bug？重複操做一次，提交不就好了？

有木有更簡單的方法？

有！

一樣的bug，要在dev上修復，咱們只須要把4c805e2 fix bug 101這個提交所作的修改「複製」到dev分支。注意：咱們只想複製4c805e2 fix bug 101這個提交所作的修改，並非把整個master分支merge過來。

爲了方便操做，Git專門提供了一個cherry-pick命令，讓咱們能複製一個特定的提交到當前分支：

$ git branch * dev master $ git cherry-pick 4c805e2 [master 1d4b803] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)

Git自動給dev分支作了一次提交，注意此次提交的commit是1d4b803，它並不一樣於master的4c805e2，由於這兩個commit只是改動相同，但確實是兩個不一樣的commit。用git cherry-pick，咱們就不須要在dev分支上手動再把修bug的過程重複一遍。

有些聰明的童鞋會想了，既然能夠在master分支上修復bug後，在dev分支上能夠「重放」這個修復過程，那麼直接在dev分支上修復bug，而後在master分支上「重放」行不行？固然能夠，不過你仍然須要git stash命令保存現場，才能從dev分支切換到master分支。

小結

修復bug時，咱們會經過建立新的bug分支進行修復，而後合併，最後刪除；

當手頭工做沒有完成時，先把工做現場git stash一下，而後去修復bug，修復後，再git stash pop，回到工做現場；

在master分支上修復的bug，想要合併到當前dev分支，能夠用git cherry-pick <commit>命令，把bug提交的修改「複製」到當前分支，避免重複勞動。

【Feature分支】

軟件開發中，總有無窮無盡的新的功能要不斷添加進來。

添加一個新功能時，你確定不但願由於一些實驗性質的代碼，把主分支搞亂了，因此，每添加一個新功能，最好新建一個feature分支，在上面開發，完成後，合併，最後，刪除該feature分支。

如今，你終於接到了一個新任務：開發代號爲Vulcan的新功能，該功能計劃用於下一代星際飛船。

因而準備開發：

$ git checkout -b feature-vulcan Switched to a new branch 'feature-vulcan'

5分鐘後，開發完畢：

$ git add vulcan.py $ git status On branch feature-vulcan Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: vulcan.py $ git commit -m "add feature vulcan" [feature-vulcan 287773e] add feature vulcan 1 file changed, 2 insertions(+) create mode 100644 vulcan.py

切回dev，準備合併：

$ git checkout dev

一切順利的話，feature分支和bug分支是相似的，合併，而後刪除。

可是！

就在此時，接到上級命令，因經費不足，新功能必須取消！

雖然白乾了，可是這個包含機密資料的分支仍是必須就地銷燬：

$ git branch -d feature-vulcan error: The branch 'feature-vulcan' is not fully merged. If you are sure you want to delete it, run 'git branch -D feature-vulcan'.

銷燬失敗。Git友情提醒，feature-vulcan分支尚未被合併，若是刪除，將丟失掉修改，若是要強行刪除，須要使用大寫的-D參數。。

如今咱們強行刪除：

$ git branch -D feature-vulcan Deleted branch feature-vulcan (was 287773e).

終於刪除成功！

小結

開發一個新feature，最好新建一個分支；

若是要丟棄一個沒有被合併過的分支，能夠經過git branch -D <name>強行刪除。

【多人協做】

當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，而且，遠程倉庫的默認名稱是origin。

要查看遠程庫的信息，用git remote：

$ git remote origin

或者，用git remote -v顯示更詳細的信息：

$ git remote -v origin git@github.com:michaelliao/learngit.git (fetch) origin git@github.com:michaelliao/learngit.git (push)

上面顯示了能夠抓取和推送的origin的地址。若是沒有推送權限，就看不到push的地址。

推送分支

推送分支，就是把該分支上的全部本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：

$ git push origin master

若是要推送其餘分支，好比dev，就改爲：

$ git push origin dev

可是，並非必定要把本地分支往遠程推送，那麼，哪些分支須要推送，哪些不須要呢？

master分支是主分支，所以要時刻與遠程同步；
dev分支是開發分支，團隊全部成員都須要在上面工做，因此也須要與遠程同步；
bug分支只用於在本地修復bug，就不必推到遠程了，除非老闆要看看你每週到底修復了幾個bug；
feature分支是否推到遠程，取決於你是否和你的小夥伴合做在上面開發。

總之，就是在Git中，分支徹底能夠在本地本身藏着玩，是否推送，視你的心情而定！

抓取分支

多人協做時，你們都會往master和dev分支上推送各自的修改。

如今，模擬一個你的小夥伴，能夠在另外一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另外一個目錄下克隆：

$ git clone git@github.com:michaelliao/learngit.git Cloning into 'learngit'... remote: Counting objects: 40, done. remote: Compressing objects: 100% (21/21), done. remote: Total 40 (delta 14), reused 40 (delta 14), pack-reused 0 Receiving objects: 100% (40/40), done. Resolving deltas: 100% (14/14), done.

當你的小夥伴從遠程庫clone時，默認狀況下，你的小夥伴只能看到本地的master分支。不信能夠用git branch命令看看：

$ git branch * master

如今，你的小夥伴要在dev分支上開發，就必須建立遠程origin的dev分支到本地，因而他用這個命令建立本地dev分支：

$ git checkout -b dev origin/dev

如今，他就能夠在dev上繼續修改，而後，時不時地把dev分支push到遠程：

$ git add env.txt

$ git commit -m "add env" [dev 7a5e5dd] add env 1 file changed, 1 insertion(+) create mode 100644 env.txt $ git push origin dev Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git f52c633..7a5e5dd dev -> dev

你的小夥伴已經向origin/dev分支推送了他的提交，而碰巧你也對一樣的文件做了修改，並試圖推送：

$ cat env.txt
env

$ git add env.txt

$ git commit -m "add new env" [dev 7bd91f1] add new env 1 file changed, 1 insertion(+) create mode 100644 env.txt $ git push origin dev To github.com:michaelliao/learngit.git ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to 'git@github.com:michaelliao/learngit.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失敗，由於你的小夥伴的最新提交和你試圖推送的提交有衝突，解決辦法也很簡單，Git已經提示咱們，先用git pull把最新的提交從origin/dev抓下來，而後，在本地合併，解決衝突，再推送：

$ git pull
There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/<branch> dev

git pull也失敗了，緣由是沒有指定本地dev分支與遠程origin/dev分支的連接，根據提示，設置dev和origin/dev的連接：

$ git branch --set-upstream-to=origin/dev dev Branch 'dev' set up to track remote branch 'dev' from 'origin'.

再pull：

$ git pull Auto-merging env.txt CONFLICT (add/add): Merge conflict in env.txt Automatic merge failed; fix conflicts and then commit the result.

這回git pull成功，可是合併有衝突，須要手動解決，解決的方法和分支管理中的解決衝突徹底同樣。解決後，提交，再push：

$ git commit -m "fix env conflict" [dev 57c53ab] fix env conflict $ git push origin dev Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git 7a5e5dd..57c53ab dev -> dev

所以，多人協做的工做模式一般是這樣：

首先，能夠試圖用git push origin <branch-name>推送本身的修改；
若是推送失敗，則由於遠程分支比你的本地更新，須要先用git pull試圖合併；
若是合併有衝突，則解決衝突，並在本地提交；
沒有衝突或者解決掉衝突後，再用git push origin <branch-name>推送就能成功！

若是git pull提示no tracking information，則說明本地分支和遠程分支的連接關係沒有建立，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

這就是多人協做的工做模式，一旦熟悉了，就很是簡單。

小結

查看遠程庫信息，使用git remote -v；
本地新建的分支若是不推送到遠程，對其餘人就是不可見的；
從本地推送分支，使用git push origin branch-name，若是推送失敗，先用git pull抓取遠程的新提交；
在本地建立和遠程分支對應的分支，使用git checkout -b branch-name origin/branch-name，本地和遠程分支的名稱最好一致；
創建本地分支和遠程分支的關聯，使用git branch --set-upstream branch-name origin/branch-name；
從遠程抓取分支，使用git pull，若是有衝突，要先處理衝突。

【Rebase】

在上一節咱們看到了，多人在同一個分支上協做時，很容易出現衝突。即便沒有衝突，後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 ...

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