遠程倉庫

到目前為止，我們已經(jīng)掌握了如何在Git倉庫里對一個文件進行時光穿梭缭嫡，你再也不用擔心文件備份或者丟失的問題了。

可是有用過集中式版本控制系統(tǒng)SVN的童鞋會站出來說，這些功能在SVN里早就有了糊饱，沒看出Git有什么特別的地方。

沒錯颠黎，如果只是在一個倉庫里管理文件歷史另锋，Git和SVN真沒啥區(qū)別。為了保證你現(xiàn)在所學的Git物超所值盏缤，將來絕對不會后悔砰蠢，同時為了打擊已經(jīng)不幸學了SVN的童鞋，本章開始介紹Git的殺手級功能之一（注意是之一唉铜，也就是后面還有之二台舱，之三……）：遠程倉庫。

Git是分布式版本控制系統(tǒng)，同一個Git倉庫竞惋，可以分布到不同的機器上柜去。怎么分布呢？最早拆宛，肯定只有一臺機器有一個原始版本庫嗓奢，此后浑厚，別的機器可以“克隆”這個原始版本庫，而且每臺機器的版本庫其實都是一樣的钳幅，并沒有主次之分震嫉。

你肯定會想票堵，至少需要兩臺機器才能玩遠程庫不是？但是我只有一臺電腦湃望，怎么玩换衬？

其實一臺電腦上也是可以克隆多個版本庫的，只要不在同一個目錄下证芭。不過瞳浦，現(xiàn)實生活中是不會有人這么傻的在一臺電腦上搞幾個遠程庫玩，因為一臺電腦上搞幾個遠程庫完全沒有意義废士，而且硬盤掛了會導致所有庫都掛掉叫潦，所以我也不告訴你在一臺電腦上怎么克隆多個倉庫。

實際情況往往是這樣官硝，找一臺電腦充當服務器的角色矗蕊，每天24小時開機，其他每個人都從這個“服務器”倉庫克隆一份到自己的電腦上氢架，并且各自把各自的提交推送到服務器倉庫里傻咖，也從服務器倉庫中拉取別人的提交。

完全可以自己搭建一臺運行Git的服務器岖研，不過現(xiàn)階段卿操，為了學Git先搭個服務器絕對是小題大作警检。好在這個世界上有個叫GitHub的神奇的網(wǎng)站，從名字就可以看出害淤，這個網(wǎng)站就是提供Git倉庫托管服務的扇雕，所以，只要注冊一個GitHub賬號窥摄，就可以免費獲得Git遠程倉庫镶奉。

在繼續(xù)閱讀后續(xù)內(nèi)容前，請自行注冊GitHub賬號崭放。由于你的本地Git倉庫和GitHub倉庫之間的傳輸是通過SSH加密的哨苛，所以，需要一點設置：

• 第1步：創(chuàng)建SSH Key币砂。在用戶主目錄下移国，看看有沒有.ssh目錄，如果有道伟，再看看這個目錄下有沒有id_rsa
  和id_rsa.pub
  這兩個文件，如果已經(jīng)有了使碾，可直接跳到下一步蜜徽。如果沒有，打開Shell（Windows下打開Git Bash）票摇，創(chuàng)建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，打開“Settings”耗溜，“SSH Keys”頁面：
  然后组力，點“SSH and GPG keys”，填上任意Title抖拴，在Key文本框里粘貼id_rsa.pub文件的內(nèi)容：
  

為什么GitHub需要SSH Key呢燎字？因為GitHub需要識別出你推送的提交確實是你推送的，而不是別人冒充的，而Git支持SSH協(xié)議轩触，所以寞酿，GitHub只要知道了你的公鑰，就可以確認只有你自己才能推送脱柱。

當然伐弹，GitHub允許你添加多個Key。假定你有若干電腦榨为，你一會兒在公司提交惨好，一會兒在家里提交，只要把每臺電腦的Key都添加到GitHub随闺，就可以在每臺電腦上往GitHub推送了日川。

最后友情提示，在GitHub上免費托管的Git倉庫矩乐，任何人都可以看到喔（但只有你自己才能改）龄句。所以，不要把敏感信息放進去散罕。

如果你不想讓別人看到Git庫分歇，有兩個辦法，一個是交點保護費欧漱，讓GitHub把公開的倉庫變成私有的职抡，這樣別人就看不見了（不可讀更不可寫）。另一個辦法是自己動手误甚，搭一個Git服務器缚甩，因為是你自己的Git服務器，所以別人也是看不見的窑邦。這個方法我們后面會講到的擅威，相當簡單，公司內(nèi)部開發(fā)必備冈钦。

確保你擁有一個GitHub賬號后裕寨，我們就即將開始遠程倉庫的學習。

小結(jié)

“有了遠程倉庫派继，媽媽再也不用擔心我的硬盤了宾袜。”——Git點讀機

添加遠程庫

現(xiàn)在的情景是驾窟，你已經(jīng)在本地創(chuàng)建了一個Git倉庫后庆猫，又想在GitHub創(chuàng)建一個Git倉庫，并且讓這兩個倉庫進行遠程同步绅络，這樣月培，GitHub上的倉庫既可以作為備份嘁字，又可以讓其他人通過該倉庫來協(xié)作，真是一舉多得杉畜。

首先纪蜒，登陸GitHub，創(chuàng)建一個新的倉庫：

目前灭袁，在GitHub上的這個learngit倉庫還是空的猬错，GitHub告訴我們，可以從這個倉庫克隆出新的倉庫茸歧，也可以把一個已有的本地倉庫與之關聯(lián)倦炒，然后，把本地倉庫的內(nèi)容推送到GitHub倉庫软瞎。

現(xiàn)在逢唤，我們根據(jù)GitHub的提示，在本地的learngit倉庫下運行命令：

git remote add origin https://github.com/9aoyang/learngit.git

添加后涤浇，遠程庫的名字就是origin智玻，這是Git默認的叫法，也可以改成別的芙代，但是origin這個名字一看就知道是遠程庫:

$ git push -u origin master
Counting objects: 17, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (17/17), 1.43 KiB | 0 bytes/s, done.
Total 17 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), done.
To https://github.com/9aoyang/learngit.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

把本地庫的內(nèi)容推送到遠程，用git push命令盖彭，實際上是把當前分支master推送到遠程纹烹。

由于遠程庫是空的，我們第一次推送master分支時召边，加上了-u參數(shù)铺呵，Git不但會把本地的master分支內(nèi)容推送的遠程新的master分支，還會把本地的master分支和遠程的master分支關聯(lián)起來隧熙，在以后的推送或者拉取時就可以簡化命令片挂。

推送成功后，可以立刻在GitHub頁面中看到遠程庫的內(nèi)容已經(jīng)和本地一模一樣：

從現(xiàn)在起贞盯，只要本地作了提交音念，就可以通過命令：

$ git push origin master

把本地master分支的最新修改推送至GitHub，現(xiàn)在躏敢，你就擁有了真正的分布式版本庫闷愤！

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會輸出一個警告旬渠，告訴你已經(jīng)把GitHub的Key添加到本機的一個信任列表里了：

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

如果你實在擔心有人冒充GitHub服務器俱萍，輸入yes
前可以對照GitHub的RSA Key的指紋信息是否與SSH連接給出的一致。

小結(jié)

要關聯(lián)一個遠程庫告丢，使用命令git remote add origin git@server-name:path/repo-name.git枪蘑；

關聯(lián)后，使用命令git push -u origin master第一次推送master分支的所有內(nèi)容芋齿；

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

分布式版本系統(tǒng)的最大好處之一是在本地工作完全不需要考慮遠程庫的存在栅炒，也就是有沒有聯(lián)網(wǎng)都可以正常工作掂摔，而SVN在沒有聯(lián)網(wǎng)的時候是拒絕干活的！當有網(wǎng)絡的時候赢赊，再把本地提交推送一下就完成了同步乙漓，真是太方便了！

從遠程庫克隆

上次我們講了先有本地庫释移，后有遠程庫的時候叭披，如何關聯(lián)遠程庫。

現(xiàn)在玩讳，假設我們從零開發(fā)涩蜘，那么最好的方式是先創(chuàng)建遠程庫，然后熏纯，從遠程庫克隆同诫。

首先，登陸GitHub樟澜，創(chuàng)建一個新的倉庫误窖，名字叫gitskills：

我們勾選Initialize this repository with a README，這樣GitHub會自動為我們創(chuàng)建一個README.md文件秩贰。創(chuàng)建完畢后霹俺，可以看到README.md文件：

Paste_Image.png

現(xiàn)在，遠程庫已經(jīng)準備好了毒费，下一步是用命令git clone克隆一個本地庫：

$ git clone git@github.com:9aoyang/gitskills.git
Cloning into 'gitskills'...
The authenticity of host 'github.com (192.30.255.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.255.112' (RSA) to the list of known hosts.
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

$ cd gitskills
$ ls
README.md

注意把Git庫的地址換成你自己的吭服，然后進入gitskills目錄看看，已經(jīng)有README.md文件了蝗罗。

如果有多個人協(xié)作開發(fā)艇棕，那么每個人各自從遠程克隆一份就可以了蝌戒。

你也許還注意到，GitHub給出的地址不止一個沼琉，還可以用https://github.com/michaelliao/gitskills.git這樣的地址北苟。實際上，Git支持多種協(xié)議打瘪，默認的git://使用ssh友鼻，但也可以使用https等其他協(xié)議。

使用https除了速度慢以外闺骚，還有個最大的麻煩是每次推送都必須輸入口令彩扔，但是在某些只開放http端口的公司內(nèi)部就無法使用ssh協(xié)議而只能用https。

小結(jié)

要克隆一個倉庫僻爽，首先必須知道倉庫的地址虫碉，然后使用git clone命令克隆。

Git支持多種協(xié)議胸梆，包括https敦捧，但通過ssh支持的原生git協(xié)議速度最快。

分支管理

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

如果兩個平行宇宙互不干擾绪颖，那對現(xiàn)在的你也沒啥影響秽荤。不過，在某個時間點柠横，兩個平行宇宙合并了窃款，結(jié)果，你既學會了Git又學會了SVN滓鸠！

learn-branches

分支在實際中有什么用呢？假設你準備開發(fā)一個新功能第喳，但是需要兩周才能完成糜俗，第一周你寫了50%的代碼，如果立刻提交曲饱，由于代碼還沒寫完悠抹，不完整的代碼庫會導致別人不能干活了。如果等代碼全部寫完再一次提交扩淀，又存在丟失每天進度的巨大風險楔敌。

現(xiàn)在有了分支，就不用怕了驻谆。你創(chuàng)建了一個屬于你自己的分支卵凑，別人看不到庆聘，還繼續(xù)在原來的分支上正常工作，而你在自己的分支上干活勺卢，想提交就提交伙判，直到開發(fā)完畢后，再一次性合并到原來的分支上黑忱，這樣宴抚，既安全，又不影響別人工作甫煞。

其他版本控制系統(tǒng)如SVN等都有分支管理菇曲，但是用過之后你會發(fā)現(xiàn)，這些版本控制系統(tǒng)創(chuàng)建和切換分支比蝸牛還慢抚吠，簡直讓人無法忍受常潮，結(jié)果分支功能成了擺設，大家都不去用埃跷。

但Git的分支是與眾不同的蕊玷，無論創(chuàng)建、切換和刪除分支弥雹，Git在1秒鐘之內(nèi)就能完成垃帅！無論你的版本庫是1個文件還是1萬個文件。

創(chuàng)建與合并分支

每次提交剪勿，Git都把它們串成一條時間線贸诚，這條時間線就是一個分支。截止到目前厕吉，只有一條時間線酱固，在Git里，這個分支叫主分支头朱，即master分支运悲。HEAD嚴格來說不是指向提交，而是指向master项钮，master才是指向提交的班眯，所以，HEAD指向的就是當前分支烁巫。

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

合并完分支后鳄橘，甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉芒炼，刪掉后瘫怜，我們就剩下了一條master分支：

下面開始實戰(zhàn)。

首先本刽，我們創(chuàng)建dev分支鲸湃，然后切換到dev分支：

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

git checkout命令加上-b參數(shù)表示創(chuàng)建并切換，相當于以下兩條命令：

$ 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.md
$ git commit -m "branch test"
[dev cc10569] branch test
 1 file changed, 2 insertions(+), 1 deletion(-)

現(xiàn)在鲜屏，dev分支的工作完成烹看，我們就可以切換回master分支：

$ git checkout master
Switched to branch 'master'

切換回master分支后，再查看一個readme.txt文件墙歪，剛才添加的內(nèi)容不見了听系！因為那個提交是在dev分支上贝奇，而master分支此刻的提交點并沒有變：

$ git merge dev
Updating 238d90f..cc10569
Fast-forward
 README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

git merge命令用于合并指定分支到當前分支。合并后掉瞳，再查看readme.txt的內(nèi)容毕源，就可以看到浪漠，和dev分支的最新提交是完全一樣的。

注意到上面的Fast-forward信息霎褐，Git告訴我們址愿，這次合并是“快進模式”，也就是直接把master指向dev的當前提交冻璃，所以合并速度非诚煳剑快。

當然省艳，也不是每次合并都能Fast-forward娘纷，我們后面會講其他方式的合并。

合并完成后跋炕，就可以放心地刪除dev分支了：

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

刪除后赖晶，查看branch，就只剩下master分支了：

$ git branch
* master

因為創(chuàng)建辐烂、合并和刪除分支非扯舨澹快，所以Git鼓勵你使用分支完成某個任務纠修，合并后再刪掉分支胳嘲，這和直接在master分支上工作效果是一樣的，但過程更安全分瘾。

小結(jié)

Git鼓勵大量使用分支：

查看分支：git branch

創(chuàng)建分支：git branch <name>

切換分支：git checkout <name>

創(chuàng)建+切換分支：git checkout -b <name>

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

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

解決沖突

人生不如意之事十之八九胎围，合并分支往往也不是一帆風順的。

準備新的feature1分支德召，繼續(xù)我們的新分支開發(fā)：

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

修改README.md最后一行白魂，改為：

Creating a new branch is quick AND simple.

在feature1分支上提交：

$ git add README.md

$ git commit -m "AND simple"
[feature1 d0dff9f] 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.md

$ git commit -m "& simple"
[master 6abbfd7] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

現(xiàn)在上岗，master分支和feature1分支各自都分別有新的提交福荸，變成了這樣：

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

果然沖突了呆瞻！Git告訴我們台夺，README.md文件存在沖突，必須手動解決沖突后再提交痴脾。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.md

no changes added to commit (use "git add" and/or "git commit -a")

我們可以直接查看README.md的內(nèi)容：

$ cat README.md
# gitskills
<<<<<<< HEAD
Creating a new branch is quick & simple
=======
Creating a new branch is quick AND simple
>>>>>>> feature1

Git用<<<<<<<颤介，=======，>>>>>>>標記出不同分支的內(nèi)容，我們修改如下后保存：

Creating a new branch is quick and simple.

再提交：

$ git add README.md

$ git commit -m "conflict fixed"
[master 8f9778f] conflict fixed

現(xiàn)在滚朵，master分支和feature1分支變成了下圖所示：

$ git log --graph --pretty=oneline --abbrev-commit
*   8f9778f conflict fixed
|\
| * d0dff9f AND simple
* | 6abbfd7 & simple
|/
* cc10569 branch test
* 238d90f Initial commit

最后冤灾，刪除feature1分支：

$ git branch -d feature1
Deleted branch feature1 (was d0dff9f).

工作完成。

小結(jié)

當Git無法自動合并分支時辕近，就必須首先解決沖突韵吨。解決沖突后，再提交移宅，合并完成归粉。

用git log --graph命令可以看到分支合并圖。

分支管理策略

通常漏峰，合并分支時盏浇，如果可能，Git會用Fast forward模式芽狗，但這種模式下绢掰，刪除分支后，會丟掉分支信息童擎。

如果要強制禁用Fast forward模式滴劲，Git就會在merge時生成一個新的commit，這樣顾复，從分支歷史上就可以看出分支信息班挖。

下面我們實戰(zhàn)一下--no-ff方式的git merge：
首先，仍然創(chuàng)建并切換dev分支：

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

修改README.md文件芯砸，并提交一個新的commit：

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

現(xiàn)在萧芙，我們切換回master：

$ git checkout master
Switched to branch 'master'

準備合并dev分支，請注意--no-ff參數(shù)假丧，表示禁用Fast forward ：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

因為本次合并要創(chuàng)建一個新的commit双揪，所以加上-m參數(shù)，把commit描述寫進去包帚。

合并后渔期，我們用git log看看分支歷史：

$ git log --graph --pretty=oneline --abbrev-commit
*   f1eda29 merge with no-ff
|\
| * 45621a8 add merge
|/
*   8f9778f conflict fixed
|\
| * d0dff9f AND simple
* | 6abbfd7 & simple
|/
* cc10569 branch test
...

可以看到，不使用Fast forward模式渴邦，merge后就像這樣：

在實際開發(fā)中疯趟，我們應該按照幾個基本原則進行分支管理：

首先，master分支應該是非常穩(wěn)定的谋梭，也就是僅用來發(fā)布新版本信峻，平時不能在上面干活；

那在哪干活呢瓮床？干活都在dev分支上盹舞，也就是說姨夹，dev分支是不穩(wěn)定的，到某個時候矾策，比如1.0版本發(fā)布時，再把dev分支合并到master上峭沦，在master分支發(fā)布1.0版本贾虽；

你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支吼鱼，時不時地往dev分支上合并就可以了蓬豁。

所以，團隊合作的分支看起來就像這樣：

Git分支十分強大菇肃，在團隊開發(fā)中應該充分應用地粪。

合并分支時，加上--no-ff參數(shù)就可以用普通模式合并琐谤，合并后的歷史有分支蟆技，能看出來曾經(jīng)做過合并，而fast forward合并就看不出來曾經(jīng)做過合并斗忌。

Bug分支

件開發(fā)中质礼，bug就像家常便飯一樣。有了bug就需要修復织阳，在Git中眶蕉，由于分支是如此的強大，所以唧躲，每個bug都可以通過一個新的臨時分支來修復造挽，修復后，合并分支弄痹，然后將臨時分支刪除饭入。

當你接到一個修復一個代號101的bug的任務時，很自然地肛真，你想創(chuàng)建一個分支issue-101來修復它圣拄，但是，等等毁欣，當前正在dev上進行的工作還沒有提交：

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
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

no changes added to commit (use "git add" and/or "git commit -a")

并不是你不想提交庇谆，而是工作只進行到一半，還沒法提交凭疮，預計完成還需1天時間饭耳。但是，必須在兩個小時內(nèi)修復該bug执解，怎么辦寞肖？

幸好纲酗，Git還提供了一個stash功能，可以把當前工作現(xiàn)場“儲藏”起來新蟆，等以后恢復現(xiàn)場后繼續(xù)工作：

$ git stash
Saved working directory and index state WIP on master: bb447bf remove test.txt
HEAD is now at bb447bf remove test.txt

現(xiàn)在觅赊，用git status查看工作區(qū)，就是干凈的（除非有沒有被Git管理的文件）琼稻，因此可以放心地創(chuàng)建分支來修復bug吮螺。

首先確定要在哪個分支上修復bug，假定需要在master分支上修復帕翻，就從master創(chuàng)建臨時分支：

$ git checkout master
Already on 'master'
Your branch is up-to-date with 'origin/master'.
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

現(xiàn)在修復bug鸠补，需要把“Git is free software ...”改為“Git is a free software ...”，然后提交：

$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 6ebfa69] fix bug 101
 1 file changed, 2 insertions(+), 2 deletions(-)

修復完成后嘀掸，切換到master分支紫岩，并完成合并，最后刪除issue-101分支：

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
$ git branch -d issue-101
Deleted branch issue-101 (was 6ebfa69).

太棒了睬塌，原計劃兩個小時的bug修復只花了5分鐘泉蝌！現(xiàn)在，是時候接著回到dev分支干活了揩晴！

$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)

工作區(qū)是干凈的梨与，剛才的工作現(xiàn)場存到哪去了？用git stash list命令看看：

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

工作現(xiàn)場還在文狱，Git把stash內(nèi)容存在某個地方了粥鞋，但是需要恢復一下，有兩個辦法：

一是用git stash apply恢復瞄崇，但是恢復后呻粹，stash內(nèi)容并不刪除，你需要用git stash drop來刪除苏研；

另一種方式是用git stash pop等浊，恢復的同時把stash內(nèi)容也刪了：

$ 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} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

再用git stash list查看，就看不到任何stash內(nèi)容了：

$ git stash list

你可以多次stash摹蘑，恢復的時候筹燕，先用git stash list查看，然后恢復指定的stash衅鹿，用命令：

$ git stash apply stash@{0}

小結(jié)

修復bug時撒踪，我們會通過創(chuàng)建新的bug分支進行修復，然后合并大渤，最后刪除制妄；

當手頭工作沒有完成時，先把工作現(xiàn)場git stash一下泵三，然后去修復bug耕捞，修復后衔掸，再git stash pop，回到工作現(xiàn)場俺抽。

Feature分支

軟件開發(fā)中敞映，總有無窮無盡的新的功能要不斷添加進來。

添加一個新功能時磷斧，你肯定不希望因為一些實驗性質(zhì)的代碼振愿，把主分支搞亂了，所以瞳抓，每添加一個新功能，最好新建一個feature分支伏恐，在上面開發(fā)孩哑，完成后，合并翠桦，最后横蜒，刪除該feature分支。

現(xiàn)在销凑，你終于接到了一個新任務：開發(fā)代號為Vulcan的新功能丛晌，該功能計劃用于下一代星際飛船。

于是準備開發(fā)：

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

五百年后斗幼，開發(fā)完畢：

$ 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 756d4af] add feature vulcan
 1 file changed, 2 insertions(+)
 create mode 100644 vulcan.py

切回dev澎蛛，準備合并：

$ git checkout dev

一切順利的話，feature分支和bug分支是類似的蜕窿，合并谋逻，然后刪除。

但是桐经，

就在此時毁兆，接到上級命令，因經(jīng)費不足阴挣，新功能必須取消气堕！

雖然白干了，但是這個分支還是必須就地銷毀：

$ 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分支還沒有被合并，如果刪除誓沸，將丟失掉修改骗爆，如果要強行刪除，需要使用命令git branch -D feature-vulcan蔽介。
現(xiàn)在我們強行刪除：

$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 756d4af).

小結(jié)

開發(fā)一個新feature摘投，最好新建一個分支煮寡；

如果要丟棄一個沒有被合并過的分支，可以通過git branch -D <name>強行刪除犀呼。

多人協(xié)作

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

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

$ git remote
origin

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

$ git remote -v
origin  https://github.com/9aoyang/learngit.git (fetch)
origin  https://github.com/9aoyang/learngit.git (push)

上面顯示了可以抓取和推送的origin的地址貌矿。如果沒有推送權限，就看不到push的地址罪佳。

推送分支
推送分支逛漫，就是把該分支上的所有本地提交推送到遠程庫。推送時赘艳，要指定本地分支酌毡，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：

$ git push origin master

如果要推送其他分支蕾管，比如dev枷踏，就改成：

$ git push origin dev

但是，并不是一定要把本地分支往遠程推送掰曾，那么旭蠕，哪些分支需要推送，哪些不需要呢旷坦？

• master分支是主分支下梢，因此要時刻與遠程同步；

• dev分支是開發(fā)分支塞蹭，團隊所有成員都需要在上面工作孽江，所以也需要與遠程同步；

• bug分支只用于在本地修復bug番电，就沒必要推到遠程了岗屏，除非老板要看看你每周到底修復了幾個bug；

• feature分支是否推到遠程漱办，取決于你是否和你的小伙伴合作在上面開發(fā)这刷。

總之，就是在Git中娩井，分支完全可以在本地自己藏著玩暇屋，是否推送，視你的心情而定洞辣！

抓取分支
多人協(xié)作時咐刨，大家都會往master和dev分支上推送各自的修改昙衅。

現(xiàn)在，模擬一個你的小伙伴定鸟，可以在另一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另一個目錄下克露妗：

$ git clone git@github.com:michaelliao/learngit.git
Cloning into 'learngit'...
remote: Counting objects: 46, done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 46 (delta 16), reused 45 (delta 15)
Receiving objects: 100% (46/46), 15.69 KiB | 6 KiB/s, done.
Resolving deltas: 100% (16/16), done.

當你的小伙伴從遠程庫clone時，默認情況下联予，你的小伙伴只能看到本地的master分支啼县。不信可以用git branch命令看看：

$ git branch
* master

現(xiàn)在，你的小伙伴要在dev分支上開發(fā)沸久，就必須創(chuàng)建遠程origin的dev分支到本地季眷，于是他用這個命令創(chuàng)建本地dev分支：

$ git checkout -b dev origin/dev

現(xiàn)在，他就可以在dev上繼續(xù)修改卷胯，然后子刮，時不時地把dev分支push到遠程：

$ git commit -m "add /usr/bin/env"
[dev 291bea8] add /usr/bin/env
 1 file changed, 1 insertion(+)
$ git push origin dev
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 349 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
   fc38031..291bea8  dev -> dev

你的小伙伴已經(jīng)向origin/dev分支推送了他的提交，而碰巧你也對同樣的文件作了修改诵竭，并試圖推送：

$ git add hello.py 
$ git commit -m "add coding: utf-8"
[dev bd6ae48] add coding: utf-8
 1 file changed, 1 insertion(+)
$ git push origin dev
To git@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. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失敗话告，因為你的小伙伴的最新提交和你試圖推送的提交有沖突兼搏，解決辦法也很簡單卵慰，Git已經(jīng)提示我們，先用git pull把最新的提交從origin/dev抓下來佛呻，然后裳朋，在本地合并，解決沖突吓著，再推送：

$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From github.com:michaelliao/learngit
   fc38031..291bea8  dev        -> origin/dev
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 dev origin/<branch>

git pull也失敗了鲤嫡，原因是沒有指定本地dev分支與遠程origin/dev分支的鏈接，根據(jù)提示绑莺，設置dev和origin/dev的鏈接：

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

再pull：

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

這回git pull成功暖眼，但是合并有沖突，需要手動解決纺裁，解決的方法和分支管理中的解決沖突完全一樣诫肠。解決后，提交欺缘，再push：

$ git commit -m "merge & fix hello.py"
[dev adca45d] merge & fix hello.py
$ git push origin dev
Counting objects: 10, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 747 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
   291bea8..adca45d  dev -> dev

因此栋豫，多人協(xié)作的工作模式通常是這樣：

1. 首先，可以試圖用git push origin branch-name推送自己的修改谚殊；

2. 如果推送失敗丧鸯，則因為遠程分支比你的本地更新，需要先用git pull試圖合并嫩絮；

3. 如果合并有沖突丛肢，則解決沖突围肥，并在本地提交；

4. 沒有沖突或者解決掉沖突后摔踱，再用git push origin branch-name推送就能成功虐先！

如果git pull提示“no tracking information”，則說明本地分支和遠程分支的鏈接關系沒有創(chuàng)建派敷，用命令git branch --set-upstream branch-name origin/branch-name蛹批。

這就是多人協(xié)作的工作模式，一旦熟悉了篮愉，就非常簡單腐芍。

小結(jié)

• 查看遠程庫信息，使用git remote -v试躏；

• 本地新建的分支如果不推送到遠程猪勇，對其他人就是不可見的；

• 從本地推送分支颠蕴，使用git push origin branch-name泣刹，如果推送失敗，先用git pull抓取遠程的新提交犀被；

• 在本地創(chuàng)建和遠程分支對應的分支椅您，使用git checkout -b branch-name origin/branch-name，本地和遠程分支的名稱最好一致寡键；

• 建立本地分支和遠程分支的關聯(lián)掀泳，使用git branch --set-upstream branch-name origin/branch-name；

從遠程抓取分支西轩，使用git pull员舵，如果有沖突，要先處理沖突藕畔。

標簽管理

發(fā)布一個版本時马僻，我們通常先在版本庫中打一個標簽（tag），這樣注服，就唯一確定了打標簽時刻的版本韭邓。將來無論什么時候，取某個標簽的版本祠汇，就是把那個打標簽的時刻的歷史版本取出來仍秤。所以，標簽也是版本庫的一個快照。

Git的標簽雖然是版本庫的快照，但其實它就是指向某個commit的指針（跟分支很像對不對稿械？但是分支可以移動拙已，標簽不能移動）苇本，所以袜茧，創(chuàng)建和刪除標簽都是瞬間完成的。

Git有commit瓣窄，為什么還要引入tag笛厦？

“請把上周一的那個版本打包發(fā)布，commit號是6a5819e...”

“一串亂七八糟的數(shù)字不好找俺夕！”

如果換一個辦法：

“請把上周一的那個版本打包發(fā)布裳凸，版本號是v1.2”

“好的，按照tag v1.2查找commit就行劝贸！”

所以姨谷，tag就是一個讓人容易記住的有意義的名字，它跟某個commit綁在一起映九。

創(chuàng)建標簽

在Git中打標簽非常簡單梦湘，首先，切換到需要打標簽的分支上：

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

然后件甥，敲命令git tag <name>就可以打一個新標簽：

$ git tag v1.0

可以用命令git tag查看所有標簽：

$ git tag
v1.0

默認標簽是打在最新提交的commit上的捌议。有時候，如果忘了打標簽引有，比如瓣颅，現(xiàn)在已經(jīng)是周五了，但應該在周一打的標簽沒有打轿曙，怎么辦弄捕？

方法是找到歷史提交的commit id僻孝，然后打上就可以了：

$ git log --pretty=oneline --abbrev-commit
6a5819e merged bug fix 101
cc17032 fix bug 101
7825a50 merge with no-ff
6224937 add merge
59bc1cb conflict fixed
400b400 & simple
75a857c AND simple
fec145a branch test
d17efd8 remove test.txt
...

比方說要對add merge這次提交打標簽导帝，它對應的commit id是6224937，敲入命令：

$ git tag v0.9 6224937

再用命令git tag查看標簽：

$ git tag
v0.9
v1.0

注意穿铆，標簽不是按時間順序列出您单，而是按字母排序的≤癯可以用git show <tagname>查看標簽信息：

$ git show v0.9
commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Thu Aug 22 11:22:08 2013 +0800

    add merge
...

可以看到虐秦，v0.9確實打在add merge這次提交上。
還可以創(chuàng)建帶有說明的標簽凤优，用-a指定標簽名悦陋，-m指定說明文字：

$ git tag -a v0.1 -m "version 0.1 released" 3628164

用命令git show <tagname>可以看到說明文字：

$ git show v0.1
tag v0.1
Tagger: Michael Liao <askxuefeng@gmail.com>
Date:   Mon Aug 26 07:28:11 2013 +0800

version 0.1 released

commit 3628164fb26d48395383f8f31179f24e0882e1e0
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Tue Aug 20 15:11:49 2013 +0800

    append GPL

(暫不用學習)還可以通過-s用私鑰簽名一個標簽：

$ git tag -s v0.2 -m "signed version 0.2 released" fec145a

簽名采用PGP簽名，因此筑辨，必須首先安裝gpg（GnuPG）俺驶，如果沒有找到gpg，或者沒有gpg密鑰對棍辕，就會報錯：

gpg: signing failed: secret key not available
error: gpg failed to sign the data
error: unable to sign the tag

如果報錯暮现，請參考GnuPG幫助文檔配置Key还绘。
用命令git show <tagname>可以看到PGP簽名信息：

$ git show v0.2
tag v0.2
Tagger: Michael Liao <askxuefeng@gmail.com>
Date:   Mon Aug 26 07:28:33 2013 +0800

signed version 0.2 released
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)

iQEcBAABAgAGBQJSGpMhAAoJEPUxHyDAhBpT4QQIAKeHfR3bo...
-----END PGP SIGNATURE-----

commit fec145accd63cdc9ed95a2f557ea0658a2a6537f
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Thu Aug 22 10:37:30 2013 +0800

    branch test

用PGP簽名的標簽是不可偽造的，因為可以驗證PGP簽名栖袋。驗證簽名的方法比較復雜拍顷，這里就不介紹了。

小結(jié)

• 命令git tag <name>用于新建一個標簽塘幅，默認為HEAD昔案，也可以指定一個commit id；

• git tag -a <tagname> -m "blablabla..."可以指定標簽信息电媳；

• git tag -s <tagname> -m "blablabla..."可以用PGP簽名標簽爱沟；

• 命令git tag可以查看所有標簽。

操作標簽

如果標簽打錯了匆背，也可以刪除：

$ git tag -d v0.1
Deleted tag 'v0.1' (was e078af9)

因為創(chuàng)建的標簽都只存儲在本地呼伸，不會自動推送到遠程。所以钝尸，打錯的標簽可以在本地安全刪除括享。

如果要推送某個標簽到遠程，使用命令git push origin <tagname>：

$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/9aoyang/learngit.git
 * [new tag]         v1.0 -> v1.0

或者珍促，一次性推送全部尚未推送到遠程的本地標簽：

$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/9aoyang/learngit.git
 * [new tag]         v0.9 -> v0.9

如果標簽已經(jīng)推送到遠程铃辖，要刪除遠程標簽就麻煩一點，先從本地刪除：

$ git tag -d v0.9
Deleted tag 'v0.9' (was 6ebfa69)

然后猪叙，從遠程刪除娇斩。刪除命令也是push，但是格式如下：

$ git push origin :refs/tags/v0.9
To https://github.com/9aoyang/learngit.git
 - [deleted]         v0.9

要看看是否真的從遠程庫刪除了標簽穴翩，可以登陸GitHub查看犬第。

刪除標簽前

刪除標簽后

命令git push origin <tagname>可以推送一個本地標簽；

命令git push origin --tags可以推送全部未推送過的本地標簽芒帕；

命令git tag -d <tagname>可以刪除一個本地標簽歉嗓；

命令git push origin :refs/tags/<tagname>可以刪除一個遠程標簽。