一. 在Mac OS X上安裝Git
如果你正在使用Mac做開發(fā)，有兩種安裝Git的方法。
一是安裝homebrew，然后通過homebrew安裝Git，具體方法請(qǐng)參考homebrew的文檔：http://brew.sh/。
第二種方法更簡單，也是推薦的方法，就是直接從AppStore安裝Xcode，Xcode集成了Git，不過默認(rèn)沒有安裝，你需要運(yùn)行Xcode，選擇菜單“Xcode”->“Preferences”，在彈出窗口中找到“Downloads”，選擇“Command Line Tools”，點(diǎn)“Install”就可以完成安裝了。
二.創(chuàng)建版本庫
初始化一個(gè)Git倉庫，使用git init命令。
添加文件到Git倉庫，分兩步：
使用命令git add <file>，注意，可反復(fù)多次使用，添加多個(gè)文件；
使用命令git commit -m <message>，完成。
三.時(shí)光機(jī)穿梭
要隨時(shí)掌握工作區(qū)的狀態(tài)，使用git status命令。
如果git status告訴你有文件被修改過，用git diff可以查看修改內(nèi)容。
1.版本回退
HEAD指向的版本就是當(dāng)前版本，因此，Git允許我們?cè)诎姹镜臍v史之間穿梭，使用命令:
git reset --hard commit_id
回退到上一版本：
git reset --hard HEAD~1
穿梭前，用git log可以查看提交歷史，以便確定要回退到哪個(gè)版本。如果嫌輸出信息太多，看得眼花繚亂的，可以試試加上--pretty=oneline參數(shù)
git log --pretty=oneline
要重返未來，用git reflog查看命令歷史，以便確定要回到未來的哪個(gè)版本。
2.撤銷修改
場(chǎng)景1：當(dāng)你改亂了工作區(qū)某個(gè)文件的內(nèi)容，想直接丟棄工作區(qū)的修改時(shí)，用命令git checkout -- file。
場(chǎng)景2：當(dāng)你不但改亂了工作區(qū)某個(gè)文件的內(nèi)容，還添加到了暫存區(qū)時(shí)，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場(chǎng)景1，第二步按場(chǎng)景1操作。
場(chǎng)景3：已經(jīng)提交了不合適的修改到版本庫時(shí)，想要撤銷本次提交，參考版本回退一節(jié)，不過前提是沒有推送到遠(yuǎn)程庫。
3.刪除文件
本地倉庫刪除了文件或者rm <file>
現(xiàn)在你有兩個(gè)選擇：
一是確實(shí)要從版本庫中刪除該文件，那就用命令git rm刪掉，并且git commit:
$ git rm test.txt
rm 'test.txt'
$ git commit -m "remove test.txt"
[master d46f35e] remove test.txt
1 file changed, 1 deletion(-)
delete mode 100644 test.txt
文件就從版本庫中被刪除了
二是刪錯(cuò)了，因?yàn)榘姹編炖镞€有呢，所以可以很輕松地把誤刪的文件恢復(fù)到最新版本：
$ git checkout -- test.txt
git checkout其實(shí)是用版本庫里的版本替換工作區(qū)的版本，無論工作區(qū)是修改還是刪除，都可以“一鍵還原”。
注意：從來沒有被添加到版本庫就被刪除的文件，是無法恢復(fù)的！
命令git rm用于刪除一個(gè)文件。如果一個(gè)文件已經(jīng)被提交到版本庫，那么你永遠(yuǎn)不用擔(dān)心誤刪，但是要小心，你只能恢復(fù)文件到最新版本，你會(huì)丟失最近一次提交后你修改的內(nèi)容。
四.遠(yuǎn)程倉庫
獲得GitHub遠(yuǎn)程倉庫
第1步：創(chuàng)建SSH Key。在用戶主目錄(user)下，看看有沒有.ssh目錄，如果有，再看看這個(gè)目錄下有沒有id_rsa和id_rsa.pub這兩個(gè)文件，如果已經(jīng)有了，可直接跳到下一步。如果沒有，打開Shell（Windows下打開Git Bash），創(chuàng)建SSH Key：
$ ssh-keygen -t rsa -C "xxxxx@mail.com"
你需要把郵件地址換成你自己的郵件地址，然后一路回車，使用默認(rèn)值即可，由于這個(gè)Key也不是用于軍事目的，所以也無需設(shè)置密碼。
如果一切順利的話，可以在用戶主目錄里找到.ssh目錄，里面有id_rsa和id_rsa.pub兩個(gè)文件，這兩個(gè)就是SSH Key的秘鑰對(duì)，id_rsa是私鑰，不能泄露出去，id_rsa.pub是公鑰，可以放心地告訴任何人。
第2步：登陸GitHub，點(diǎn)擊右上角頭像，選擇Settings，SSH and GPG keys頁面;
然后，點(diǎn)New SSH Key，填上任意Title，在Key文本框里粘貼id_rsa.pub文件的內(nèi)容;
點(diǎn)Add SSH Key，你就應(yīng)該看到已經(jīng)添加的Key;
為什么GitHub需要SSH Key呢？因?yàn)镚itHub需要識(shí)別出你推送的提交確實(shí)是你推送的，而不是別人冒充的，而Git支持SSH協(xié)議，所以，GitHub只要知道了你的公鑰，就可以確認(rèn)只有你自己才能推送。
當(dāng)然，GitHub允許你添加多個(gè)Key。假定你有若干電腦，你一會(huì)兒在公司提交，一會(huì)兒在家里提交，只要把每臺(tái)電腦的Key都添加到GitHub，就可以在每臺(tái)電腦上往GitHub推送了。
最后友情提示，在GitHub上免費(fèi)托管的Git倉庫，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放進(jìn)去。
如果你不想讓別人看到Git庫，有兩個(gè)辦法，一個(gè)是交點(diǎn)保護(hù)費(fèi)，讓GitHub把公開的倉庫變成私有的，這樣別人就看不見了（不可讀更不可寫）。另一個(gè)辦法是自己動(dòng)手，搭一個(gè)Git服務(wù)器，因?yàn)槭悄阕约旱腉it服務(wù)器，所以別人也是看不見的。這個(gè)方法我們后面會(huì)講到的，相當(dāng)簡單，公司內(nèi)部開發(fā)必備。
1.添加遠(yuǎn)程庫
現(xiàn)在的情景是，你已經(jīng)在本地創(chuàng)建了一個(gè)Git倉庫后，又想在GitHub創(chuàng)建一個(gè)Git倉庫，并且讓這兩個(gè)倉庫進(jìn)行遠(yuǎn)程同步，這樣，GitHub上的倉庫既可以作為備份，又可以讓其他人通過該倉庫來協(xié)作，真是一舉多得。
首先，登陸GitHub，然后，在右上角+號(hào)找到New repository按鈕，創(chuàng)建一個(gè)新的倉庫;
在Repository name填入倉庫名learngit，其他保持默認(rèn)設(shè)置，點(diǎn)擊Create repository按鈕，就成功地創(chuàng)建了一個(gè)新的Git倉庫;
目前，在GitHub上的這個(gè)learngit倉庫還是空的，GitHub告訴我們，可以從這個(gè)倉庫克隆出新的倉庫，也可以把一個(gè)已有的本地倉庫與之關(guān)聯(lián)，然后，把本地倉庫的內(nèi)容推送到GitHub倉庫。
現(xiàn)在，我們根據(jù)GitHub的提示，在本地的learngit倉庫下運(yùn)行命令：
$ git remote add origin git@github.com:xxxxx/learngit.git
請(qǐng)千萬注意，把上面的xxxxx替換成你自己的GitHub賬戶名，否則，你在本地關(guān)聯(lián)的就是別人的遠(yuǎn)程庫，關(guān)聯(lián)沒有問題，但是你以后推送是推不上去的，因?yàn)槟愕腟SH Key公鑰不在別人的賬戶列表中。
添加后，遠(yuǎn)程庫的名字就是origin，這是Git默認(rèn)的叫法，也可以改成別的，但是origin這個(gè)名字一看就知道是遠(yuǎn)程庫。
下一步，就可以把本地庫的所有內(nèi)容推送到遠(yuǎn)程庫上：
$ 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'.
把本地庫的內(nèi)容推送到遠(yuǎn)程，用git push命令，實(shí)際上是把當(dāng)前分支master推送到遠(yuǎn)程。
由于遠(yuǎn)程庫是空的，我們第一次推送master分支時(shí)，加上了-u參數(shù)，Git不但會(huì)把本地的master分支內(nèi)容推送的遠(yuǎn)程新的master分支，還會(huì)把本地的master分支和遠(yuǎn)程的master分支關(guān)聯(lián)起來，在以后的推送或者拉取時(shí)就可以簡化命令。
從現(xiàn)在起，只要本地作了提交，就可以通過命令：
$ git push origin master
把本地master分支的最新修改推送至GitHub，現(xiàn)在，你就擁有了真正的分布式版本庫！
SSH警告
當(dāng)你第一次使用Git的clone或者push命令連接GitHub時(shí)，會(huì)得到一個(gè)警告：
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)?
這是因?yàn)镚it使用SSH連接，而SSH連接在第一次驗(yàn)證GitHub服務(wù)器的Key時(shí)，需要你確認(rèn)GitHub的Key的指紋信息是否真的來自GitHub的服務(wù)器，輸入yes回車即可。
Git會(huì)輸出一個(gè)警告，告訴你已經(jīng)把GitHub的Key添加到本機(jī)的一個(gè)信任列表里了：
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
這個(gè)警告只會(huì)出現(xiàn)一次，后面的操作就不會(huì)有任何警告了。
如果你實(shí)在擔(dān)心有人冒充GitHub服務(wù)器，輸入yes前可以對(duì)照GitHub的RSA Key的指紋信息是否與SSH連接給出的一致。
小結(jié)
要關(guān)聯(lián)一個(gè)遠(yuǎn)程庫，使用命令git remote add origin git@server-name:path/repo-name.git；
關(guān)聯(lián)后，使用命令git push -u origin master第一次推送master分支的所有內(nèi)容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
分布式版本系統(tǒng)的最大好處之一是在本地工作完全不需要考慮遠(yuǎn)程庫的存在，也就是有沒有聯(lián)網(wǎng)都可以正常工作，而SVN在沒有聯(lián)網(wǎng)的時(shí)候是拒絕干活的！當(dāng)有網(wǎng)絡(luò)的時(shí)候，再把本地提交推送一下就完成了同步，真是太方便了！
2.從遠(yuǎn)程庫克隆
首先，登陸GitHub，創(chuàng)建一個(gè)新的倉庫，名字叫gitskills;
勾選Initialize this repository with a README，這樣GitHub會(huì)自動(dòng)為我們創(chuàng)建一個(gè)README.md文件。創(chuàng)建完畢后，可以看到README.md文件；
現(xiàn)在，遠(yuǎn)程庫已經(jīng)準(zhǔn)備好了，下一步是用命令git clone克隆一個(gè)本地庫:
$ git clone git@github.com:xxxxx/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庫的地址換成你自己的，然后進(jìn)入gitskills目錄看看，已經(jīng)有README.md文件了：
$ cd gitskills
$ ls
README.md
如果有多個(gè)人協(xié)作開發(fā)，那么每個(gè)人各自從遠(yuǎn)程克隆一份就可以了。
你也許還注意到，GitHub給出的地址不止一個(gè)，還可以用https://github.com/michaelliao/gitskills.git這樣的地址。實(shí)際上，Git支持多種協(xié)議，默認(rèn)的git://使用ssh，但也可以使用https等其他協(xié)議。
使用https除了速度慢以外，還有個(gè)最大的麻煩是每次推送都必須輸入口令，但是在某些只開放http端口的公司內(nèi)部就無法使用ssh協(xié)議而只能用https。
小結(jié)
要克隆一個(gè)倉庫，首先必須知道倉庫的地址，然后使用git clone命令克隆。
Git支持多種協(xié)議，包括https，但通過ssh支持的原生git協(xié)議速度最快。
五.分支管理
分支就是科幻電影里面的平行宇宙，當(dāng)你正在電腦前努力學(xué)習(xí)Git的時(shí)候，另一個(gè)你正在另一個(gè)平行宇宙里努力學(xué)習(xí)SVN。
如果兩個(gè)平行宇宙互不干擾，那對(duì)現(xiàn)在的你也沒啥影響。不過，在某個(gè)時(shí)間點(diǎn)，兩個(gè)平行宇宙合并了，結(jié)果，你既學(xué)會(huì)了Git又學(xué)會(huì)了SVN！
分支在實(shí)際中有什么用呢？假設(shè)你準(zhǔn)備開發(fā)一個(gè)新功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還沒寫完，不完整的代碼庫會(huì)導(dǎo)致別人不能干活了。如果等代碼全部寫完再一次提交，又存在丟失每天進(jìn)度的巨大風(fēng)險(xiǎn)。
現(xiàn)在有了分支，就不用怕了。你創(chuàng)建了一個(gè)屬于你自己的分支，別人看不到，還繼續(xù)在原來的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到開發(fā)完畢后，再一次性合并到原來的分支上，這樣，既安全，又不影響別人工作。
其他版本控制系統(tǒng)如SVN等都有分支管理，但是用過之后你會(huì)發(fā)現(xiàn)，這些版本控制系統(tǒng)創(chuàng)建和切換分支比蝸牛還慢，簡直讓人無法忍受，結(jié)果分支功能成了擺設(shè)，大家都不去用。
但Git的分支是與眾不同的，無論創(chuàng)建、切換和刪除分支，Git在1秒鐘之內(nèi)就能完成！無論你的版本庫是1個(gè)文件還是1萬個(gè)文件。
1.創(chuàng)建與合并分支
首先，我們創(chuàng)建dev分支，然后切換到dev分支：
$ git checkout -b dev
Switched to a new branch 'dev'
git checkout命令加上-b參數(shù)表示創(chuàng)建并切換，相當(dāng)于以下兩條命令：
$ git branch dev
$ git checkout dev
Switched to branch 'dev'
然后，用git branch命令查看當(dāng)前分支：
$ git branch
* dev
master
git branch命令會(huì)列出所有分支，當(dāng)前分支前面會(huì)標(biāo)一個(gè)*號(hào)。
然后，我們就可以在dev分支上正常提交，比如對(duì)readme.txt做個(gè)修改，加上一行：
Creating a new branch is quick.
然后提交：
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+)
現(xiàn)在，dev分支的工作完成，我們就可以切換回master分支：
$ git checkout master
Switched to branch 'master'
切換回master分支后，再查看一個(gè)readme.txt文件，剛才添加的內(nèi)容不見了！因?yàn)槟莻€(gè)提交是在dev分支上，而master分支此刻的提交點(diǎn)并沒有變;
現(xiàn)在，我們把dev分支的工作成果合并到master分支上：
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge命令用于合并指定分支到當(dāng)前分支。合并后，再查看readme.txt的內(nèi)容，就可以看到，和dev分支的最新提交是完全一樣的。
注意到上面的Fast-forward信息，Git告訴我們，這次合并是“快進(jìn)模式”，也就是直接把master指向dev的當(dāng)前提交，所以合并速度非?？臁?/p>
當(dāng)然，也不是每次合并都能Fast-forward，我們后面會(huì)講其他方式的合并。
合并完成后，就可以放心地刪除dev分支了：
$ git branch -d dev
Deleted branch dev (was b17d20e).
刪除后，查看branch，就只剩下master分支了：
$ git branch
* master
因?yàn)閯?chuàng)建、合并和刪除分支非常快，所以Git鼓勵(lì)你使用分支完成某個(gè)任務(wù)，合并后再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。
小結(jié)
Git鼓勵(lì)大量使用分支：
查看分支：git branch
創(chuàng)建分支：git branch <name>
切換分支：git checkout <name>
創(chuàng)建+切換分支：git checkout -b <name>
合并某分支到當(dāng)前分支：git merge <name>
刪除分支：git branch -d <name>
2.解決沖突
人生不如意之事十之八九，合并分支往往也不是一帆風(fēng)順的。
準(zhǔn)備新的feature1分支，繼續(xù)我們的新分支開發(fā)：
$ 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還會(huì)自動(dòng)提示我們當(dāng)前master分支比遠(yuǎn)程的master分支要超前1個(gè)提交。
在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(-)
現(xiàn)在，master分支和feature1分支各自都分別有新的提交;
這種情況下，Git無法執(zhí)行“快速合并”，只能試圖把各自的修改合并起來，但這種合并就可能會(huì)有沖突，我們?cè)囋嚳矗?/p>
$ 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文件存在沖突，必須手動(dòng)解決沖突后再提交。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的內(nèi)容：
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用<<<<<<<，=======，>>>>>>>標(biāo)記出不同分支的內(nèi)容，我們修改如下后保存：
Creating a new branch is quick and simple.
再提交：
$ git add readme.txt
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed
現(xiàn)在，master分支和feature1分支變成了下圖所示：
[圖片上傳失敗...(image-bd478-1557217136484)]
用帶參數(shù)的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).
小結(jié)
當(dāng)Git無法自動(dòng)合并分支時(shí)，就必須首先解決沖突。解決沖突后，再提交，合并完成。
解決沖突就是把Git合并失敗的文件手動(dòng)編輯為我們希望的內(nèi)容，再提交。
用git log --graph命令可以看到分支合并圖。
git log --graph --pretty=oneline --abbrev-commit
3.分支管理策略
通常，合并分支時(shí)，如果可能，Git會(huì)用Fast forward模式，但這種模式下，刪除分支后，會(huì)丟掉分支信息。
如果要強(qiáng)制禁用Fast forward模式，Git就會(huì)在merge時(shí)生成一個(gè)新的commit，這樣，從分支歷史上就可以看出分支信息。
下面我們實(shí)戰(zhàn)一下--no-ff方式的git merge：
首先，仍然創(chuàng)建并切換dev分支：
$ git checkout -b dev
Switched to a new branch 'dev'
修改readme.txt文件，并提交一個(gè)新的commit：
$ git add readme.txt
$ git commit -m "add merge"
[dev f52c633] add merge
1 file changed, 1 insertion(+)
現(xiàn)在，我們切換回master：
$ git checkout master
Switched to branch 'master'
準(zhǔn)備合并dev分支，請(qǐng)注意--no-ff參數(shù)，表示禁用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(+)
因?yàn)楸敬魏喜⒁獎(jiǎng)?chuàng)建一個(gè)新的commit，所以加上-m參數(shù)，把commit描述寫進(jìn)去。
合并后，我們用git log看看分支歷史：
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
分支策略
在實(shí)際開發(fā)中，我們應(yīng)該按照幾個(gè)基本原則進(jìn)行分支管理：
首先，master分支應(yīng)該是非常穩(wěn)定的，也就是僅用來發(fā)布新版本，平時(shí)不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是說，dev分支是不穩(wěn)定的，到某個(gè)時(shí)候，比如1.0版本發(fā)布時(shí)，再把dev分支合并到master上，在master分支發(fā)布1.0版本；
你和你的小伙伴們每個(gè)人都在dev分支上干活，每個(gè)人都有自己的分支，時(shí)不時(shí)地往dev分支上合并就可以了。
小結(jié)
Git分支十分強(qiáng)大，在團(tuán)隊(duì)開發(fā)中應(yīng)該充分應(yīng)用。
合并分支時(shí)，加上--no-ff參數(shù)就可以用普通模式合并，合并后的歷史有分支，能看出來曾經(jīng)做過合并，而fast forward合并就看不出來曾經(jīng)做過合并。
5.Bug分支
軟件開發(fā)中，bug就像家常便飯一樣。有了bug就需要修復(fù)，在Git中，由于分支是如此的強(qiáng)大，所以，每個(gè)bug都可以通過一個(gè)新的臨時(shí)分支來修復(fù)，修復(fù)后，合并分支，然后將臨時(shí)分支刪除。
當(dāng)你接到一個(gè)修復(fù)一個(gè)代號(hào)101的bug的任務(wù)時(shí)，很自然地，你想創(chuàng)建一個(gè)分支issue-101來修復(fù)它，但是，等等，當(dāng)前正在dev上進(jìn)行的工作還沒有提交：
$ 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
并不是你不想提交，而是工作只進(jìn)行到一半，還沒法提交，預(yù)計(jì)完成還需1天時(shí)間。但是，必須在兩個(gè)小時(shí)內(nèi)修復(fù)該bug，怎么辦？
幸好，Git還提供了一個(gè)stash功能，可以把當(dāng)前工作現(xiàn)場(chǎng)“儲(chǔ)藏”起來，等以后恢復(fù)現(xiàn)場(chǎng)后繼續(xù)工作：
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
現(xiàn)在，用git status查看工作區(qū)，就是干凈的（除非有沒有被Git管理的文件），因此可以放心地創(chuàng)建分支來修復(fù)bug。
首先確定要在哪個(gè)分支上修復(fù)bug，假定需要在master分支上修復(fù)，就從master創(chuàng)建臨時(shí)分支：
$ 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'
現(xiàn)在修復(fù)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(-)
修復(fù)完成后，切換到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(-)
太棒了，原計(jì)劃兩個(gè)小時(shí)的bug修復(fù)只花了5分鐘！現(xiàn)在，是時(shí)候接著回到dev分支干活了！
$ git checkout dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean
工作區(qū)是干凈的，剛才的工作現(xiàn)場(chǎng)存到哪去了？用git stash list命令看看：
$ git stash list
stash@{0}: WIP on dev: f52c633 add merge
工作現(xiàn)場(chǎng)還在，Git把stash內(nèi)容存在某個(gè)地方了，但是需要恢復(fù)一下，有兩個(gè)辦法：
一是用git stash apply恢復(fù)，但是恢復(fù)后，stash內(nèi)容并不刪除，你需要用git stash drop來刪除；
另一種方式是用git stash pop，恢復(fù)的同時(shí)把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} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
再用git stash list查看，就看不到任何stash內(nèi)容了：
$ git stash list
你可以多次stash，恢復(fù)的時(shí)候，先用git stash list查看，然后恢復(fù)指定的stash，用命令：
$ git stash apply stash@{0}
小結(jié)
修復(fù)bug時(shí)，我們會(huì)通過創(chuàng)建新的bug分支進(jìn)行修復(fù)，然后合并，最后刪除；
當(dāng)手頭工作沒有完成時(shí)，先把工作現(xiàn)場(chǎng)git stash一下，然后去修復(fù)bug，修復(fù)后，再git stash pop，回到工作現(xiàn)場(chǎng)。
6.Feature分支
軟件開發(fā)中，總有無窮無盡的新的功能要不斷添加進(jìn)來。
添加一個(gè)新功能時(shí)，你肯定不希望因?yàn)橐恍?shí)驗(yàn)性質(zhì)的代碼，把主分支搞亂了，所以，每添加一個(gè)新功能，最好新建一個(gè)feature分支，在上面開發(fā)，完成后，合并，最后，刪除該feature分支。
現(xiàn)在，你終于接到了一個(gè)新任務(wù)：開發(fā)代號(hào)為Vulcan的新功能，該功能計(jì)劃用于下一代星際飛船。
于是準(zhǔn)備開發(fā)：
$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'
5分鐘后，開發(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 287773e] add feature vulcan
1 file changed, 2 insertions(+)
create mode 100644 vulcan.py
切回dev，準(zhǔn)備合并：
$ git checkout dev
一切順利的話，feature分支和bug分支是類似的，合并，然后刪除。
但是！
就在此時(shí)，接到上級(jí)命令，因經(jīng)費(fèi)不足，新功能必須取消！
雖然白干了，但是這個(gè)包含機(jī)密資料的分支還是必須就地銷毀：
$ 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分支還沒有被合并，如果刪除，將丟失掉修改，如果要強(qiáng)行刪除，需要使用大寫的-D參數(shù)。。
現(xiàn)在我們強(qiáng)行刪除：
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 287773e).
終于刪除成功！
小結(jié)
開發(fā)一個(gè)新feature，最好新建一個(gè)分支；
如果要丟棄一個(gè)沒有被合并過的分支，可以通過git branch -D <name>強(qiáng)行刪除。
7.多人協(xié)作
當(dāng)你從遠(yuǎn)程倉庫克隆時(shí)，實(shí)際上Git自動(dòng)把本地的master分支和遠(yuǎn)程的master分支對(duì)應(yīng)起來了，并且，遠(yuǎn)程倉庫的默認(rèn)名稱是origin。
要查看遠(yuǎn)程庫的信息，用git remote：
$ git remote
origin
或者，用git remote -v顯示更詳細(xì)的信息：
$ git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
上面顯示了可以抓取和推送的origin的地址。如果沒有推送權(quán)限，就看不到push的地址。
推送分支
推送分支，就是把該分支上的所有本地提交推送到遠(yuǎn)程庫。推送時(shí)，要指定本地分支，這樣，Git就會(huì)把該分支推送到遠(yuǎn)程庫對(duì)應(yīng)的遠(yuǎn)程分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev
但是，并不是一定要把本地分支往遠(yuǎn)程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要時(shí)刻與遠(yuǎn)程同步；dev分支是開發(fā)分支，團(tuán)隊(duì)所有成員都需要在上面工作，所以也需要與遠(yuǎn)程同步；bug分支只用于在本地修復(fù)bug，就沒必要推到遠(yuǎn)程了，除非老板要看看你每周到底修復(fù)了幾個(gè)bug；
feature分支是否推到遠(yuǎn)程，取決于你是否和你的小伙伴合作在上面開發(fā)。
總之，就是在Git中，分支完全可以在本地自己藏著玩，是否推送，視你的心情而定！
抓取分支
多人協(xié)作時(shí)，大家都會(huì)往master和dev分支上推送各自的修改。
現(xiàn)在，模擬一個(gè)你的小伙伴，可以在另一臺(tái)電腦（注意要把SSH Key添加到GitHub）或者同一臺(tái)電腦的另一個(gè)目錄下克?。?/p>
$ 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.
當(dāng)你的小伙伴從遠(yuǎn)程庫clone時(shí)，默認(rèn)情況下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：
$ git branch
* master
現(xiàn)在，你的小伙伴要在dev分支上開發(fā)，就必須創(chuàng)建遠(yuǎn)程origin的dev分支到本地，于是他用這個(gè)命令創(chuàng)建本地dev分支：
$ git checkout -b dev origin/dev
現(xiàn)在，他就可以在dev上繼續(xù)修改，然后，時(shí)不時(shí)地把dev分支push到遠(yuǎn)程：
$ 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
你的小伙伴已經(jīng)向origin/dev分支推送了他的提交，而碰巧你也對(duì)同樣的文件作了修改，并試圖推送：
$ 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.
推送失敗，因?yàn)槟愕男』锇榈淖钚绿峤缓湍阍噲D推送的提交有沖突，解決辦法也很簡單，Git已經(jīng)提示我們，先用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分支與遠(yuǎn)程origin/dev分支的鏈接，根據(jù)提示，設(shè)置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成功，但是合并有沖突，需要手動(dòng)解決，解決的方法和分支管理中的解決沖突完全一樣。解決后，提交，再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
因此，多人協(xié)作的工作模式通常是這樣：
首先，可以試圖用
git push origin <branch-name>推送自己的修改；如果推送失敗，則因?yàn)檫h(yuǎn)程分支比你的本地更新，需要先用
git pull試圖合并；如果合并有沖突，則解決沖突，并在本地提交；
沒有沖突或者解決掉沖突后，再用
git push origin <branch-name>推送就能成功！
如果git pull提示no tracking information，則說明本地分支和遠(yuǎn)程分支的鏈接關(guān)系沒有創(chuàng)建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
這就是多人協(xié)作的工作模式，一旦熟悉了，就非常簡單。
小結(jié)
查看遠(yuǎn)程庫信息，使用
git remote -v；本地新建的分支如果不推送到遠(yuǎn)程，對(duì)其他人就是不可見的；
從本地推送分支，使用
git push origin branch-name，如果推送失敗，先用git pull抓取遠(yuǎn)程的新提交；在本地創(chuàng)建和遠(yuǎn)程分支對(duì)應(yīng)的分支，使用
git checkout -b branch-name origin/branch-name，本地和遠(yuǎn)程分支的名稱最好一致；建立本地分支和遠(yuǎn)程分支的關(guān)聯(lián)，使用
git branch --set-upstream branch-name origin/branch-name；從遠(yuǎn)程抓取分支，使用
git pull，如果有沖突，要先處理沖突。
8.Rebase
多人在同一個(gè)分支上協(xié)作時(shí)，很容易出現(xiàn)沖突。即使沒有沖突，后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
總之看上去很亂，有強(qiáng)迫癥的童鞋會(huì)問：為什么Git的提交歷史不能是一條干凈的直線？
其實(shí)是可以做到的！
Git有一種稱為rebase的操作，有人把它翻譯成“變基”。
先不要隨意展開想象。我們還是從實(shí)際問題出發(fā)，看看怎么把分叉的提交變成直線。
在和遠(yuǎn)程分支同步后，我們對(duì)hello.py這個(gè)文件做了兩次提交。用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)標(biāo)識(shí)出當(dāng)前分支的HEAD和遠(yuǎn)程origin的位置分別是582d922 add author和d1be385 init hello，本地分支比遠(yuǎn)程分支快兩個(gè)提交。
現(xiàn)在我們嘗試推送本地分支：
$ 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.
很不幸，失敗了，這說明有人先于我們推送了遠(yuǎn)程分支。按照經(jīng)驗(yàn)，先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看看狀態(tài)：
$ 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
加上剛才合并的提交，現(xiàn)在我們本地分支比遠(yuǎn)程分支超前3個(gè)提交。
用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
...
對(duì)強(qiáng)迫癥童鞋來說，現(xiàn)在事情有點(diǎn)不對(duì)頭，提交歷史分叉了。如果現(xiàn)在把本地分支push到遠(yuǎn)程，有沒有問題？
有！
什么問題？
不好看！
有沒有解決方法？
有！
這個(gè)時(shí)候，rebase就派上了用場(chǎng)。我們輸入命令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
...
原本分叉的提交現(xiàn)在變成一條直線了！這種神奇的操作是怎么實(shí)現(xiàn)的？其實(shí)原理非常簡單。我們注意觀察，發(fā)現(xiàn)Git把我們本地的提交“挪動(dòng)”了位置，放到了f005ed4 (origin/master) set exit=1之后，這樣，整個(gè)提交歷史就成了一條直線。rebase操作前后，最終的提交內(nèi)容是一致的，但是，我們本地的commit修改內(nèi)容已經(jīng)變化了，它們的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4內(nèi)容是一致的。
這就是rebase操作的特點(diǎn)：把分叉的提交歷史“整理”成一條直線，看上去更直觀。缺點(diǎn)是本地的分叉提交已經(jīng)被修改過了。
最后，通過push操作把本地分支推送到遠(yuǎn)程：
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
...
遠(yuǎn)程分支的提交歷史也是一條直線。
小結(jié)
rebase操作可以把本地未push的分叉提交歷史整理成直線；
rebase的目的是使得我們?cè)诓榭礆v史提交的變化時(shí)更容易，因?yàn)榉植娴奶峤恍枰綄?duì)比。
六.標(biāo)簽管理
發(fā)布一個(gè)版本時(shí)，我們通常先在版本庫中打一個(gè)標(biāo)簽（tag），這樣，就唯一確定了打標(biāo)簽時(shí)刻的版本。將來無論什么時(shí)候，取某個(gè)標(biāo)簽的版本，就是把那個(gè)打標(biāo)簽的時(shí)刻的歷史版本取出來。所以，標(biāo)簽也是版本庫的一個(gè)快照。
Git的標(biāo)簽雖然是版本庫的快照，但其實(shí)它就是指向某個(gè)commit的指針（跟分支很像對(duì)不對(duì)？但是分支可以移動(dòng)，標(biāo)簽不能移動(dòng)），所以，創(chuàng)建和刪除標(biāo)簽都是瞬間完成的。
Git有commit，為什么還要引入tag？
“請(qǐng)把上周一的那個(gè)版本打包發(fā)布，commit號(hào)是6a5819e...”
“一串亂七八糟的數(shù)字不好找！”
如果換一個(gè)辦法：
“請(qǐng)把上周一的那個(gè)版本打包發(fā)布，版本號(hào)是v1.2”
“好的，按照tag v1.2查找commit就行！”
所以，tag就是一個(gè)讓人容易記住的有意義的名字，它跟某個(gè)commit綁在一起。
1.創(chuàng)建標(biāo)簽
在Git中打標(biāo)簽非常簡單，首先，切換到需要打標(biāo)簽的分支上：
$ git branch
* dev
master
$ git checkout master
Switched to branch 'master'
然后，敲命令git tag <name>就可以打一個(gè)新標(biāo)簽：
$ git tag v1.0
可以用命令git tag查看所有標(biāo)簽：
$ git tag
v1.0
默認(rèn)標(biāo)簽是打在最新提交的commit上的。有時(shí)候，如果忘了打標(biāo)簽，比如，現(xiàn)在已經(jīng)是周五了，但應(yīng)該在周一打的標(biāo)簽沒有打，怎么辦？
方法是找到歷史提交的commit id，然后打上就可以了：
$ git log --pretty=oneline --abbrev-commit
12a631b (HEAD -> master, tag: v1.0, origin/master) merged bug fix 101
4c805e2 fix bug 101
e1e9c68 merge with no-ff
f52c633 add merge
cf810e4 conflict fixed
5dc6824 & simple
14096d0 AND simple
b17d20e branch test
d46f35e 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
比方說要對(duì)add merge這次提交打標(biāo)簽，它對(duì)應(yīng)的commit id是f52c633，敲入命令：
$ git tag v0.9 f52c633
再用命令git tag查看標(biāo)簽：
$ git tag
v0.9
v1.0
注意，標(biāo)簽不是按時(shí)間順序列出，而是按字母排序的?？梢杂胓it show <tagname>查看標(biāo)簽信息：
$ git show v0.9
commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9)
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:56:54 2018 +0800
add merge
diff --git a/readme.txt b/readme.txt
...
可以看到，v0.9確實(shí)打在add merge這次提交上。
還可以創(chuàng)建帶有說明的標(biāo)簽，用-a指定標(biāo)簽名，-m指定說明文字：
$ git tag -a v0.1 -m "version 0.1 released" 1094adb
用命令git show <tagname>可以看到說明文字：
$ git show v0.1
tag v0.1
Tagger: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 22:48:43 2018 +0800
version 0.1 released
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (tag: v0.1)
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:06:15 2018 +0800
append GPL
diff --git a/readme.txt b/readme.txt
...
注意：標(biāo)簽總是和某個(gè)commit掛鉤。如果這個(gè)commit既出現(xiàn)在master分支，又出現(xiàn)在dev分支，那么在這兩個(gè)分支上都可以看到這個(gè)標(biāo)簽。
小結(jié)
命令git tag <tagname>用于新建一個(gè)標(biāo)簽，默認(rèn)為HEAD，也可以指定一個(gè)commit id；
命令git tag -a <tagname> -m "blablabla..."可以指定標(biāo)簽信息；
命令git tag可以查看所有標(biāo)簽。
2.操作標(biāo)簽
如果標(biāo)簽打錯(cuò)了，也可以刪除：
$ git tag -d v0.1
Deleted tag 'v0.1' (was f15b0dd)
因?yàn)閯?chuàng)建的標(biāo)簽都只存儲(chǔ)在本地，不會(huì)自動(dòng)推送到遠(yuǎn)程。所以，打錯(cuò)的標(biāo)簽可以在本地安全刪除。
如果要推送某個(gè)標(biāo)簽到遠(yuǎn)程，使用命令git push origin <tagname>：
$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v1.0 -> v1.0
或者，一次性推送全部尚未推送到遠(yuǎn)程的本地標(biāo)簽：
$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v0.9 -> v0.9
如果標(biāo)簽已經(jīng)推送到遠(yuǎn)程，要?jiǎng)h除遠(yuǎn)程標(biāo)簽就麻煩一點(diǎn)，先從本地刪除：
$ git tag -d v0.9
Deleted tag 'v0.9' (was f52c633)
然后，從遠(yuǎn)程刪除。刪除命令也是push，但是格式如下：
$ git push origin :refs/tags/v0.9
To github.com:michaelliao/learngit.git
- [deleted] v0.9
要看看是否真的從遠(yuǎn)程庫刪除了標(biāo)簽，可以登陸GitHub查看。
小結(jié)
命令git push origin <tagname>可以推送一個(gè)本地標(biāo)簽；
命令git push origin --tags可以推送全部未推送過的本地標(biāo)簽；
命令git tag -d <tagname>可以刪除一個(gè)本地標(biāo)簽；
命令git push origin :refs/tags/<tagname>可以刪除一個(gè)遠(yuǎn)程標(biāo)簽。
七.使用GitHub
我們一直用GitHub作為免費(fèi)的遠(yuǎn)程倉庫，如果是個(gè)人的開源項(xiàng)目，放到GitHub上是完全沒有問題的。其實(shí)GitHub還是一個(gè)開源協(xié)作社區(qū)，通過GitHub，既可以讓別人參與你的開源項(xiàng)目，也可以參與別人的開源項(xiàng)目。
在GitHub出現(xiàn)以前，開源項(xiàng)目開源容易，但讓廣大人民群眾參與進(jìn)來比較困難，因?yàn)橐獏⑴c，就要提交代碼，而給每個(gè)想提交代碼的群眾都開一個(gè)賬號(hào)那是不現(xiàn)實(shí)的，因此，群眾也僅限于報(bào)個(gè)bug，即使能改掉bug，也只能把diff文件用郵件發(fā)過去，很不方便。
但是在GitHub上，利用Git極其強(qiáng)大的克隆和分支功能，廣大人民群眾真正可以第一次自由參與各種開源項(xiàng)目了。
如何參與一個(gè)開源項(xiàng)目呢？比如人氣極高的bootstrap項(xiàng)目，這是一個(gè)非常強(qiáng)大的CSS框架，你可以訪問它的項(xiàng)目主頁https://github.com/twbs/bootstrap，點(diǎn)“Fork”就在自己的賬號(hào)下克隆了一個(gè)bootstrap倉庫，然后，從自己的賬號(hào)下clone：
git clone git@github.com:michaelliao/bootstrap.git
一定要從自己的賬號(hào)下clone倉庫，這樣你才能推送修改。如果從bootstrap的作者的倉庫地址git@github.com:twbs/bootstrap.git克隆，因?yàn)闆]有權(quán)限，你將不能推送修改。
Bootstrap的官方倉庫twbs/bootstrap、你在GitHub上克隆的倉庫my/bootstrap，以及你自己克隆到本地電腦的倉庫，他們的關(guān)系就像下圖顯示的那樣：
┌─ GitHub ────────────────────────────────────┐
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ twbs/bootstrap │────>│ my/bootstrap │ │
│ └─────────────────┘ └─────────────────┘ │
│ ▲ │
└──────────────────────────────────┼──────────┘
▼
┌─────────────────┐
│ local/bootstrap │
└─────────────────┘
如果你想修復(fù)bootstrap的一個(gè)bug，或者新增一個(gè)功能，立刻就可以開始干活，干完后，往自己的倉庫推送。
如果你希望bootstrap的官方庫能接受你的修改，你就可以在GitHub上發(fā)起一個(gè)pull request。當(dāng)然，對(duì)方是否接受你的pull request就不一定了。
如果你沒能力修改bootstrap，但又想要試一把pull request，那就Fork一下我的倉庫：https://github.com/ZWP233/learngit，創(chuàng)建一個(gè)your-github-id.txt的文本文件，寫點(diǎn)自己學(xué)習(xí)Git的心得，然后推送一個(gè)pull request給我，我會(huì)視心情而定是否接受。
小結(jié)
在GitHub上，可以任意Fork開源倉庫；
自己擁有Fork后的倉庫的讀寫權(quán)限；
可以推送pull request給官方倉庫來貢獻(xiàn)代碼。
八.使用碼云
使用GitHub時(shí)，國內(nèi)的用戶經(jīng)常遇到的問題是訪問速度太慢，有時(shí)候還會(huì)出現(xiàn)無法連接的情況（原因你懂的）。
如果我們希望體驗(yàn)Git飛一般的速度，可以使用國內(nèi)的Git托管服務(wù)——碼云（gitee.com）。
和GitHub相比，碼云也提供免費(fèi)的Git倉庫。此外，還集成了代碼質(zhì)量檢測(cè)、項(xiàng)目演示等功能。對(duì)于團(tuán)隊(duì)協(xié)作開發(fā)，碼云還提供了項(xiàng)目管理、代碼托管、文檔管理的服務(wù)，5人以下小團(tuán)隊(duì)免費(fèi)。
碼云的免費(fèi)版本也提供私有庫功能，只是有5人的成員上限。
使用碼云和使用GitHub類似，我們?cè)诖a云上注冊(cè)賬號(hào)并登錄后，需要先上傳自己的SSH公鑰。選擇右上角用戶頭像 -> 菜單“修改資料”，然后選擇“SSH公鑰”，填寫一個(gè)便于識(shí)別的標(biāo)題，然后把用戶主目錄下的.ssh/id_rsa.pub文件的內(nèi)容粘貼進(jìn)去;
點(diǎn)擊“確定”即可完成并看到剛才添加的Key;
如果我們已經(jīng)有了一個(gè)本地的git倉庫（例如，一個(gè)名為learngit的本地庫），如何把它關(guān)聯(lián)到碼云的遠(yuǎn)程庫上呢？
首先，我們?cè)诖a云上創(chuàng)建一個(gè)新的項(xiàng)目，選擇右上角用戶頭像 -> 菜單“控制面板”，然后點(diǎn)擊“創(chuàng)建項(xiàng)目”;
項(xiàng)目名稱最好與本地庫保持一致：
然后，我們?cè)诒镜貛焐鲜褂妹?code>git remote add把它和碼云的遠(yuǎn)程庫關(guān)聯(lián)：
git remote add origin git@gitee.com:liaoxuefeng/learngit.git
之后，就可以正常地用git push和git pull推送了！
如果在使用命令git remote add時(shí)報(bào)錯(cuò)：
git remote add origin git@gitee.com:liaoxuefeng/learngit.git
fatal: remote origin already exists.
這說明本地庫已經(jīng)關(guān)聯(lián)了一個(gè)名叫origin的遠(yuǎn)程庫，此時(shí)，可以先用git remote -v查看遠(yuǎn)程庫信息：
git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
可以看到，本地庫已經(jīng)關(guān)聯(lián)了origin的遠(yuǎn)程庫，并且，該遠(yuǎn)程庫指向GitHub。
我們可以刪除已有的GitHub遠(yuǎn)程庫：
git remote rm origin
再關(guān)聯(lián)碼云的遠(yuǎn)程庫（注意路徑中需要填寫正確的用戶名）：
git remote add origin git@gitee.com:liaoxuefeng/learngit.git
此時(shí)，我們?cè)俨榭催h(yuǎn)程庫信息：
git remote -v
origin git@gitee.com:liaoxuefeng/learngit.git (fetch)
origin git@gitee.com:liaoxuefeng/learngit.git (push)
現(xiàn)在可以看到，origin已經(jīng)被關(guān)聯(lián)到碼云的遠(yuǎn)程庫了。通過git push命令就可以把本地庫推送到Gitee上。
有的小伙伴又要問了，一個(gè)本地庫能不能既關(guān)聯(lián)GitHub，又關(guān)聯(lián)碼云呢？
答案是肯定的，因?yàn)間it本身是分布式版本控制系統(tǒng)，可以同步到另外一個(gè)遠(yuǎn)程庫，當(dāng)然也可以同步到另外兩個(gè)遠(yuǎn)程庫。
使用多個(gè)遠(yuǎn)程庫時(shí)，我們要注意，git給遠(yuǎn)程庫起的默認(rèn)名稱是origin，如果有多個(gè)遠(yuǎn)程庫，我們需要用不同的名稱來標(biāo)識(shí)不同的遠(yuǎn)程庫。
仍然以learngit本地庫為例，我們先刪除已關(guān)聯(lián)的名為origin的遠(yuǎn)程庫：
git remote rm origin
然后，先關(guān)聯(lián)GitHub的遠(yuǎn)程庫：
git remote add github git@github.com:michaelliao/learngit.git
注意，遠(yuǎn)程庫的名稱叫github，不叫origin了。
接著，再關(guān)聯(lián)碼云的遠(yuǎn)程庫：
git remote add gitee git@gitee.com:liaoxuefeng/learngit.git
同樣注意，遠(yuǎn)程庫的名稱叫gitee，不叫origin。
現(xiàn)在，我們用git remote -v查看遠(yuǎn)程庫信息，可以看到兩個(gè)遠(yuǎn)程庫：
git remote -v
gitee git@gitee.com:liaoxuefeng/learngit.git (fetch)
gitee git@gitee.com:liaoxuefeng/learngit.git (push)
github git@github.com:michaelliao/learngit.git (fetch)
github git@github.com:michaelliao/learngit.git (push)
如果要推送到GitHub，使用命令：
git push github master
如果要推送到碼云，使用命令：
git push gitee master
這樣一來，我們的本地庫就可以同時(shí)與多個(gè)遠(yuǎn)程庫互相同步：
┌─────────┐ ┌─────────┐
│ GitHub │ │ Gitee │
└─────────┘ └─────────┘
▲ ▲
└─────┬─────┘
│
┌─────────────┐
│ Local Repo │
└─────────────┘
碼云也同樣提供了Pull request功能，可以讓其他小伙伴參與到開源項(xiàng)目中來。你可以通過Fork我的倉庫：https://gitee.com/ZWP233/learngit，創(chuàng)建一個(gè)your-gitee-id.txt的文本文件， 寫點(diǎn)自己學(xué)習(xí)Git的心得，然后推送一個(gè)pull request給我，這個(gè)倉庫會(huì)在碼云和GitHub做雙向同步。
九.自定義Git
在安裝Git一節(jié)中，我們已經(jīng)配置了user.name和user.email，實(shí)際上，Git還有很多可配置項(xiàng)。
比如，讓Git顯示顏色，會(huì)讓命令輸出看起來更醒目：
$ git config --global color.ui true
這樣，Git會(huì)適當(dāng)?shù)仫@示不同的顏色，比如git status命令;
文件名就會(huì)標(biāo)上顏色。
我們?cè)诤竺孢€會(huì)介紹如何更好地配置Git，以便讓你的工作更高效。
1.忽略特殊文件
有些時(shí)候，你必須把某些文件放到Git工作目錄中，但又不能提交它們，比如保存了數(shù)據(jù)庫密碼的配置文件啦，等等，每次git status都會(huì)顯示Untracked files ...，有強(qiáng)迫癥的童鞋心里肯定不爽。
好在Git考慮到了大家的感受，這個(gè)問題解決起來也很簡單，在Git工作區(qū)的根目錄下創(chuàng)建一個(gè)特殊的.gitignore文件，然后把要忽略的文件名填進(jìn)去，Git就會(huì)自動(dòng)忽略這些文件。
不需要從頭寫.gitignore文件，GitHub已經(jīng)為我們準(zhǔn)備了各種配置文件，只需要組合一下就可以使用了。所有配置文件可以直接在線瀏覽：https://github.com/github/gitignore
忽略文件的原則是：
- 忽略操作系統(tǒng)自動(dòng)生成的文件，比如縮略圖等；
- 忽略編譯生成的中間文件、可執(zhí)行文件等，也就是如果一個(gè)文件是通過另一個(gè)文件自動(dòng)生成的，那自動(dòng)生成的文件就沒必要放進(jìn)版本庫，比如Java編譯產(chǎn)生的
.class文件； - 忽略你自己的帶有敏感信息的配置文件，比如存放口令的配置文件。
舉個(gè)例子：
假設(shè)你在Windows下進(jìn)行Python開發(fā)，Windows會(huì)自動(dòng)在有圖片的目錄下生成隱藏的縮略圖文件，如果有自定義目錄，目錄下就會(huì)有Desktop.ini文件，因此你需要忽略Windows自動(dòng)生成的垃圾文件：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
然后，繼續(xù)忽略Python編譯產(chǎn)生的.pyc、.pyo、dist等文件或目錄：
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
加上你自己定義的文件，最終得到一個(gè)完整的.gitignore文件，內(nèi)容如下：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
# My configurations:
db.ini
deploy_key_rsa
最后一步就是把.gitignore也提交到Git，就完成了！當(dāng)然檢驗(yàn).gitignore的標(biāo)準(zhǔn)是git status命令是不是說working directory clean。
使用Windows的童鞋注意了，如果你在資源管理器里新建一個(gè).gitignore文件，它會(huì)非常弱智地提示你必須輸入文件名，但是在文本編輯器里“保存”或者“另存為”就可以把文件保存為.gitignore了。
有些時(shí)候，你想添加一個(gè)文件到Git，但發(fā)現(xiàn)添加不了，原因是這個(gè)文件被.gitignore忽略了：
$ git add App.class
The following paths are ignored by one of your .gitignore files:
App.class
Use -f if you really want to add them.
如果你確實(shí)想添加該文件，可以用-f強(qiáng)制添加到Git：
$ git add -f App.class
或者你發(fā)現(xiàn)，可能是.gitignore寫得有問題，需要找出來到底哪個(gè)規(guī)則寫錯(cuò)了，可以用git check-ignore命令檢查：
$ git check-ignore -v App.class
.gitignore:3:*.class App.class
Git會(huì)告訴我們，.gitignore的第3行規(guī)則忽略了該文件，于是我們就可以知道應(yīng)該修訂哪個(gè)規(guī)則。
小結(jié)
忽略某些文件時(shí)，需要編寫
.gitignore；.gitignore文件本身要放到版本庫里，并且可以對(duì).gitignore做版本管理！
2.配置別名
有沒有經(jīng)常敲錯(cuò)命令？比如git status？status這個(gè)單詞真心不好記。
如果敲git st就表示git status那就簡單多了，當(dāng)然這種偷懶的辦法我們是極力贊成的。
我們只需要敲一行命令，告訴Git，以后st就表示status：
$ git config --global alias.st status
好了，現(xiàn)在敲git st看看效果。
當(dāng)然還有別的命令可以簡寫，很多人都用co表示checkout，ci表示commit，br表示branch：
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
以后提交就可以簡寫成：
$ git ci -m "bala bala bala..."
--global參數(shù)是全局參數(shù)，也就是這些命令在這臺(tái)電腦的所有Git倉庫下都有用。
在撤銷修改一節(jié)中，我們知道，命令git reset HEAD file可以把暫存區(qū)的修改撤銷掉（unstage），重新放回工作區(qū)。既然是一個(gè)unstage操作，就可以配置一個(gè)unstage別名：
$ git config --global alias.unstage 'reset HEAD'
當(dāng)你敲入命令：
$ git unstage test.py
實(shí)際上Git執(zhí)行的是：
$ git reset HEAD test.py
配置一個(gè)git last，讓其顯示最后一次提交信息：
$ git config --global alias.last 'log -1'
這樣，用git last就能顯示最近一次的提交：
$ git last
commit adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2
Merge: bd6ae48 291bea8
Author: Michael Liao <askxuefeng@gmail.com>
Date: Thu Aug 22 22:49:22 2013 +0800
merge & fix hello.py
甚至還有人喪心病狂地把lg配置成了：
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
為什么不早點(diǎn)告訴我？別激動(dòng)，咱不是為了多記幾個(gè)英文單詞嘛！
配置文件
配置Git的時(shí)候，加上--global是針對(duì)當(dāng)前用戶起作用的，如果不加，那只針對(duì)當(dāng)前的倉庫起作用。
配置文件放哪了？每個(gè)倉庫的Git配置文件都放在.git/config文件中：
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = git@github.com:michaelliao/learngit.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[alias]
last = log -1
別名就在[alias]后面，要?jiǎng)h除別名，直接把對(duì)應(yīng)的行刪掉即可。
而當(dāng)前用戶的Git配置文件放在用戶主目錄下的一個(gè)隱藏文件.gitconfig中：
$ cat .gitconfig
[alias]
co = checkout
ci = commit
br = branch
st = status
[user]
name = Your Name
email = your@email.com
配置別名也可以直接修改這個(gè)文件，如果改錯(cuò)了，可以刪掉文件重新通過命令配置。
小結(jié)
給Git配置好別名，就可以輸入命令時(shí)偷個(gè)懶。我們鼓勵(lì)偷懶。
3.搭建Git服務(wù)器
在遠(yuǎn)程倉庫一節(jié)中，我們講了遠(yuǎn)程倉庫實(shí)際上和本地倉庫沒啥不同，純粹為了7x24小時(shí)開機(jī)并交換大家的修改。
GitHub就是一個(gè)免費(fèi)托管開源代碼的遠(yuǎn)程倉庫。但是對(duì)于某些視源代碼如生命的商業(yè)公司來說，既不想公開源代碼，又舍不得給GitHub交保護(hù)費(fèi)，那就只能自己搭建一臺(tái)Git服務(wù)器作為私有倉庫使用。
搭建Git服務(wù)器需要準(zhǔn)備一臺(tái)運(yùn)行Linux的機(jī)器，強(qiáng)烈推薦用Ubuntu或Debian，這樣，通過幾條簡單的apt命令就可以完成安裝。
假設(shè)你已經(jīng)有sudo權(quán)限的用戶賬號(hào)，下面，正式開始安裝。
第一步，安裝git：
$ sudo apt-get install git
第二步，創(chuàng)建一個(gè)git用戶，用來運(yùn)行git服務(wù)：
$ sudo adduser git
第三步，創(chuàng)建證書登錄：
收集所有需要登錄的用戶的公鑰，就是他們自己的id_rsa.pub文件，把所有公鑰導(dǎo)入到/home/git/.ssh/authorized_keys文件里，一行一個(gè)。
第四步，初始化Git倉庫：
先選定一個(gè)目錄作為Git倉庫，假定是/srv/sample.git，在/srv目錄下輸入命令：
$ sudo git init --bare sample.git
Git就會(huì)創(chuàng)建一個(gè)裸倉庫，裸倉庫沒有工作區(qū)，因?yàn)榉?wù)器上的Git倉庫純粹是為了共享，所以不讓用戶直接登錄到服務(wù)器上去改工作區(qū)，并且服務(wù)器上的Git倉庫通常都以.git結(jié)尾。然后，把owner改為git：
$ sudo chown -R git:git sample.git
第五步，禁用shell登錄：
出于安全考慮，第二步創(chuàng)建的git用戶不允許登錄shell，這可以通過編輯/etc/passwd文件完成。找到類似下面的一行：
git:x:1001:1001:,,,:/home/git:/bin/bash
改為：
git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell
這樣，git用戶可以正常通過ssh使用git，但無法登錄shell，因?yàn)槲覀優(yōu)?code>git用戶指定的git-shell每次一登錄就自動(dòng)退出。
第六步，克隆遠(yuǎn)程倉庫：
現(xiàn)在，可以通過git clone命令克隆遠(yuǎn)程倉庫了，在各自的電腦上運(yùn)行：
$ git clone git@server:/srv/sample.git
Cloning into 'sample'...
warning: You appear to have cloned an empty repository.
剩下的推送就簡單了。
管理公鑰
如果團(tuán)隊(duì)很小，把每個(gè)人的公鑰收集起來放到服務(wù)器的/home/git/.ssh/authorized_keys文件里就是可行的。如果團(tuán)隊(duì)有幾百號(hào)人，就沒法這么玩了，這時(shí)，可以用Gitosis來管理公鑰。
這里我們不介紹怎么玩Gitosis了，幾百號(hào)人的團(tuán)隊(duì)基本都在500強(qiáng)了，相信找個(gè)高水平的Linux管理員問題不大。
管理權(quán)限
有很多不但視源代碼如生命，而且視員工為竊賊的公司，會(huì)在版本控制系統(tǒng)里設(shè)置一套完善的權(quán)限控制，每個(gè)人是否有讀寫權(quán)限會(huì)精確到每個(gè)分支甚至每個(gè)目錄下。因?yàn)镚it是為Linux源代碼托管而開發(fā)的，所以Git也繼承了開源社區(qū)的精神，不支持權(quán)限控制。不過，因?yàn)镚it支持鉤子（hook），所以，可以在服務(wù)器端編寫一系列腳本來控制提交等操作，達(dá)到權(quán)限控制的目的。Gitolite就是這個(gè)工具。
這里我們也不介紹Gitolite了，不要把有限的生命浪費(fèi)到權(quán)限斗爭中。
小結(jié)
git
