git命令總結

git命令總結
1.建立版本庫
初始化一個版本庫
git init <dir> 或者 cd <dir> git init
添加文件到版本庫
git add <file>
git commit -m "comment"

2.查看狀態
查看工做區狀態
git status
若是git status告訴文件已經被修改，查看修改內容：
git diff <file>

3.版本回退
HEAD 指向當前版本，在版本的歷史記錄之間切換：
git reset --hard commit_id
回退到上一版本：
git reset --hard HEAD^
回退到上上一版本：
git reset --hard HEAD^^
回退前100次版本
git reset --hard HEAD~100
查看版本歷史，以肯定回退到哪一個版本：
git log
git log --pretty=oneline
git log --online --decorate --graph --all
要重返將來，查看命令歷史：
git reflog

4.管理修改
查看工做區和版本庫裏面最新版本的區別
git diff HEAD -- <file>

5.撤銷修改
當你改亂了工做區某個文件的內容，想直接丟棄工做區的修改時，用命令
git checkout -- <file> 文件在工做區的修改所有撤銷

當你不但改亂了工做區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，
第一步用命令git reset HEAD <file>(把暫存區的修改撤銷)，就回到了場景1
第二步按場景1操做。

已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。

6.刪除文件
git add test.txt
git commit -m "add test.txt"
rm test.txt
git status
git rm test.txt
git commit -m "remove test.txt"
刪錯了，由於版本庫裏還有呢，因此能夠很輕鬆地把誤刪的文件恢復到最新版本：
git checkout -- test.txt

7.配置github
第1步：建立SSH Key：
在用戶主目錄下，查看有沒有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。

8.github上添加遠程倉庫
首先，登錄GitHub，而後，在右上角找到「Create a new repo」按鈕，建立一個新的倉庫
在Repository name填入learngit，其餘保持默認設置，點擊「Create repository」按鈕，就成功地建立了一個新的Git倉庫：

將本地倉庫與遠程倉庫關聯：
git remote add origin git@github.com:ileveli/learngit.git
添加後，遠程庫的名字就是origin，這是Git默認的叫法，也能夠改爲別的，可是origin這個名字一看就知道是遠程庫。

就能夠把本地庫的全部內容推送到遠程庫上：
git push -u origin master
把本地庫的內容推送到遠程，用git push命令，其實是把當前分支master推送到遠程。

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

從如今起，只要本地做了提交，就能夠經過命令：
git push origin master
把本地master分支的最新修改推送至GitHub，如今，你就擁有了真正的分佈式版本庫！

小結：
要關聯一個遠程庫，使用命令git remote add origin git@server-name:path/repo-name.git；
關聯後，使用命令git push -u origin master第一次推送master分支的全部內容；
此後，每次本地提交後，只要有必要，就可使用命令git push origin master推送最新修改；

9.從遠程庫克隆
首先，登錄GitHub，建立一個新的倉庫，名字叫gitskills
咱們勾選Initialize this repository with a README，這樣GitHub會自動爲咱們建立一個README.md文件。建立完畢後，能夠看到README.md文件
如今，遠程庫已經準備好了，下一步是用命令git clone克隆一個本地庫：
git clone git@github.com:ileveli/gitskills.git
進入gitskills目錄看看，已經有README.md文件了。

小結
要克隆一個倉庫，首先必須知道倉庫的地址，而後使用git clone命令克隆。
Git支持多種協議，包括https，但經過ssh支持的原生git協議速度最快。

10.建立與合併分支
建立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 fec145a] 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 d17efd8..fec145a
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 fec145a).
刪除後，查看branch，就只剩下master分支了：
$ git branch
* master
由於建立、合併和刪除分支很是快，因此Git鼓勵你使用分支完成某個任務，合併後再刪掉分支，這和直接在master分支上工做效果是同樣的，但過程更安全。

小結
Git鼓勵大量使用分支：
查看分支：git branch
建立分支：git branch <name>
切換分支：git checkout <name>
建立+切換分支：git checkout -b <name>
合併某分支到當前分支：git merge <name>
刪除分支：git branch -d <name>

11.解決衝突
準備新的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 75a857c] 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.
Git還會自動提示咱們當前master分支比遠程的master分支要超前1個提交。
在master分支上把readme.txt文件的最後一行改成：
Creating a new branch is quick & simple.
提交：
$ git add readme.txt
$ git commit -m "& simple"
[master 400b400] & 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
咱們能夠直接查看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 59bc1cb] conflict fixed
如今，master分支和feature1分支變成了下圖所示：
用帶參數的git log也能夠看到分支的合併狀況：
$ git log --graph --pretty=oneline --abbrev-commit
* 59bc1cb conflict fixed
|\
| * 75a857c AND simple
* | 400b400 & simple
|/
* fec145a branch test
...
最後，刪除feature1分支：
$ git branch -d feature1
Deleted branch feature1 (was 75a857c).
工做完成。

小結
當Git沒法自動合併分支時，就必須首先解決衝突。解決衝突後，再提交，合併完成。
用git log --graph命令能夠看到分支合併圖。

12.分支管理策略
一般，合併分支時，若是可能，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 6224937] 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
* 7825a50 merge with no-ff
|\
| * 6224937 add merge
|/
* 59bc1cb conflict fixed
...
能夠看到，不使用Fast forward模式，merge後就像這樣：

分支策略，在實際開發中，咱們應該按照幾個基本原則進行分支管理：
首先，master分支應該是很是穩定的，也就是僅用來發布新版本，平時不能在上面幹活；
那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，好比1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本；
你和你的小夥伴們每一個人都在dev分支上幹活，每一個人都有本身的分支，時不時地往dev分支上合併就能夠了。
因此，團隊合做的分支看起來就像這樣：
git-br-policy

小結
Git分支十分強大，在團隊開發中應該充分應用。
合併分支時，加上--no-ff參數就能夠用普通模式合併，合併後的歷史有分支，能看出來曾經作過合併，而fast forward合併就看不出來曾經作過合併。

13.BUG分支
軟件開發中，bug就像屢見不鮮同樣。有了bug就須要修復，在Git中，因爲分支是如此的強大，因此，每一個bug均可以經過一個新的臨時分支來修復，修復後，合併分支，而後將臨時分支刪除。
當你接到一個修復一個代號10的bug的任務時，很天然地，你想建立一個分支issue-10來修復它，可是，等等，當前正在dev上進行的工做尚未提交：
$ git status
並非你不想提交，而是工做只進行到一半，還無法提交，預計完成還需1天時間。可是，必須在兩個小時內修復該bug，怎麼辦？

幸虧，Git還提供了一個stash功能，能夠把當前工做現場「儲藏」起來，等之後恢復現場後繼續工做：
$ git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 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.
$ git checkout -b issue-10
Switched to a new branch 'issue-10'
如今修復bug，須要把「Git is free software ...」改成「Git is a free software ...」，而後提交：
$ git add readme.txt
$ git commit -m "fix bug 10"
[issue-101 cc17032] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
修復完成後，切換到master分支，並完成合並，最後刪除issue-10分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
$ git merge --no-ff -m "merged bug fix 101" issue-10
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-10
Deleted branch issue-10 (was cc17032).
太棒了，原計劃兩個小時的bug修復只花了5分鐘！如今，是時候接着回到dev分支幹活了！
$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)
工做區是乾淨的，剛纔的工做現場存到哪去了？用git stash list命令看看：
$ git stash list
stash@{0}: WIP on dev: 6224937 add merge
工做現場還在，Git把stash內容存在某個地方了，可是須要恢復一下，有兩個辦法：
一是用git stash apply恢復，可是恢復後，stash內容並不刪除，你須要用git stash drop來刪除；
另外一種方式是用git stash pop，恢復的同時把stash內容也刪了：
$ git stash pop
再用git stash list查看，就看不到任何stash內容了：
$ git stash list
你能夠屢次stash，恢復的時候，先用git stash list查看，而後恢復指定的stash，用命令：
$ git stash apply stash@{0}

小結
修復bug時，咱們會經過建立新的bug分支進行修復，而後合併，最後刪除；
當手頭工做沒有完成時，先把工做現場git stash一下，而後去修復bug，修復後，再git stash pop，回到工做現場。

14.Feature分支
軟件開發中，總有無窮無盡的新的功能要不斷添加進來。
添加一個新功能時，你確定不但願由於一些實驗性質的代碼，把主分支搞亂了，因此，每添加一個新功能，最好新建一個feature分支，在上面開發，完成後，合併，最後，刪除該feature分支。
如今，你終於接到了一個新任務：開發代號爲Vulcan的新功能，該功能計劃用於下一代星際飛船。
因而準備開發：
$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'
5分鐘後，開發完畢：
$ git add vulcan.py
$ git status
$ 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分支是相似的，合併，而後刪除。
可是，就在此時，接到上級命令，因經費不足，新功能必須取消！
雖然白乾了，可是這個分支仍是必須就地銷燬：
$ 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。
如今咱們強行刪除：
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 756d4af).
終於刪除成功！

小結
開發一個新feature，最好新建一個分支；
若是要丟棄一個沒有被合併過的分支，能夠經過git branch -D <name>強行刪除。

15.多人協做
當你從遠程倉庫克隆時，實際上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
當你的小夥伴從遠程庫clone時，默認狀況下，你的小夥伴只能看到本地的master分支。不信能夠用git branch命令看看：
$ git branch
* master
如今，你的小夥伴要在dev分支上開發，就必須建立遠程origin的dev分支到本地，因而他用這個命令建立本地dev分支：
$ git checkout -b dev origin/dev
如今，他就能夠在dev上繼續修改，而後，時不時地把dev分支push到遠程：
$ git commit -m "add /usr/bin/env"
$ git push origin dev
你的小夥伴已經向origin/dev分支推送了他的提交，而碰巧你也對一樣的文件做了修改，並試圖推送：
$ git add hello.py
$ git commit -m "add coding: utf-8"
$ git push origin dev
推送失敗，由於你的小夥伴的最新提交和你試圖推送的提交有衝突，解決辦法也很簡單，Git已經提示咱們，先用git pull把最新的提交從origin/dev抓下來，而後，在本地合併，解決衝突，再推送：
$ git pull
git pull也失敗了，緣由是沒有指定本地dev分支與遠程origin/dev分支的連接，根據提示，設置dev和origin/dev的連接：
$ git branch --set-upstream dev origin/dev
再pull：
$ git pull
這回git pull成功，可是合併有衝突，須要手動解決，解決的方法和分支管理中的解決衝突徹底同樣。解決後，提交，再push：
$ git commit -m "merge & fix hello.py"
$ git push origin dev

多人協做的工做模式：
首先，能夠試圖用git push origin branch-name推送本身的修改；
若是推送失敗，則由於遠程分支比你的本地更新，須要先用git pull試圖合併；
若是合併有衝突，則解決衝突，並在本地提交；
沒有衝突或者解決掉衝突後，再用git push origin branch-name推送就能成功！
若是git pull提示「no tracking information」，則說明本地分支和遠程分支的連接關係沒有建立，用命令git branch --set-upstream 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，若是有衝突，要先處理衝突。

16.標籤管理
發佈一個版本時，咱們一般先在版本庫中打一個標籤（tag），這樣，就惟一肯定了打標籤時刻的版本。未來不管何時，取某個標籤的版本，就是把那個打標籤的時刻的歷史版本取出來。因此，標籤也是版本庫的一個快照。

Git的標籤雖然是版本庫的快照，但其實它就是指向某個commit的指針（跟分支很像對不對？可是分支能夠移動，標籤不能移動），因此，建立和刪除標籤都是瞬間完成的。

Git有commit，爲何還要引入tag？
「請把上週一的那個版本打包發佈，commit號是6a5819e...」
「一串亂七八糟的數字很差找！」
若是換一個辦法：「請把上週一的那個版本打包發佈，版本號是v1.2」
「好的，按照tag v1.2查找commit就行！」
因此，tag就是一個讓人容易記住的有意義的名字，它跟某個commit綁在一塊兒。

17.建立標籤
在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上的。有時候，若是忘了打標籤，好比，如今已是週五了，但應該在週一打的標籤沒有打，怎麼辦？
方法是找到歷史提交的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此次提交上。

還能夠建立帶有說明的標籤，用-a指定標籤名，-m指定說明文字：
$ git tag -a v0.1 -m "version 0.1 released" 3628164
用命令git show <tagname>能夠看到說明文字：
$ git show v0.1
tag v0.1
還能夠經過-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簽名。驗證簽名的方法比較複雜，這裏就不介紹了。

小結
命令git tag <name>用於新建一個標籤，默認爲HEAD，也能夠指定一個commit id；
git tag -a <tagname> -m "blablabla..."能夠指定標籤信息；
git tag -s <tagname> -m "blablabla..."能夠用PGP簽名標籤；
命令git tag能夠查看全部標籤。

18.操做標籤
若是標籤打錯了，也能夠刪除：
$ git tag -d v0.1
Deleted tag 'v0.1' (was e078af9)
由於建立的標籤都只存儲在本地，不會自動推送到遠程。因此，打錯的標籤能夠在本地安全刪除。

若是要推送某個標籤到遠程，使用命令git push origin <tagname>：
$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
* [new tag] v1.0 -> v1.0
或者，一次性推送所有還沒有推送到遠程的本地標籤：
$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 554 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
* [new tag] v0.2 -> v0.2
* [new tag] v0.9 -> v0.9
若是標籤已經推送到遠程，要刪除遠程標籤就麻煩一點，先從本地刪除：
$ git tag -d v0.9
Deleted tag 'v0.9' (was 6224937)
而後，從遠程刪除。刪除命令也是push，可是格式以下：
$ git push origin :refs/tags/v0.9
To git@github.com:michaelliao/learngit.git
- [deleted] v0.9
要看看是否真的從遠程庫刪除了標籤，能夠登錄GitHub查看。

小結
命令git push origin <tagname>能夠推送一個本地標籤；
命令git push origin --tags能夠推送所有未推送過的本地標籤；
命令git tag -d <tagname>能夠刪除一個本地標籤；
命令git push origin :refs/tags/<tagname>能夠刪除一個遠程標籤。

19.使用GitHub
咱們一直用GitHub做爲免費的遠程倉庫，若是是我的的開源項目，放到GitHub上是徹底沒有問題的。其實GitHub仍是一個開源協做社區，經過GitHub，既可讓別人參與你的開源項目，也能夠參與別人的開源項目。

在GitHub出現之前，開源項目開源容易，但讓廣大人民羣衆參與進來比較困難，由於要參與，就要提交代碼，而給每一個想提交代碼的羣衆都開一個帳號那是不現實的，所以，羣衆也僅限於報個bug，即便能改掉bug，也只能把diff文件用郵件發過去，很不方便。

可是在GitHub上，利用Git極其強大的克隆和分支功能，廣大人民羣衆真正能夠第一次自由參與各類開源項目了。

如何參與一個開源項目呢？好比人氣極高的bootstrap項目，這是一個很是強大的CSS框架，你能夠訪問它的項目主頁https://github.com/twbs/bootstrap，點「Fork」就在本身的帳號下克隆了一個bootstrap倉庫，而後，從本身的帳號下clone：
git clone git@github.com:michaelliao/bootstrap.git

必定要從本身的帳號下clone倉庫，這樣你才能推送修改。若是從bootstrap的做者的倉庫地址git@github.com:twbs/bootstrap.git克隆，由於沒有權限，你將不能推送修改。

Bootstrap的官方倉庫twbs/bootstrap、你在GitHub上克隆的倉庫my/bootstrap，以及你本身克隆到本地電腦的倉庫，他們的關係就像下圖顯示的那樣：
github-repos
若是你想修復bootstrap的一個bug，或者新增一個功能，馬上就能夠開始幹活，幹完後，往本身的倉庫推送。

若是你但願bootstrap的官方庫能接受你的修改，你就能夠在GitHub上發起一個pull request。固然，對方是否接受你的pull request就不必定了。

若是你沒能力修改bootstrap，但又想要試一把pull request，那就Fork一下個人倉庫：https://github.com/michaelliao/learngit，建立一個your-github-id.txt的文本文件，寫點本身學習Git的心得，而後推送一個pull request給我，我會視心情而定是否接受。

小結
在GitHub上，能夠任意Fork開源倉庫；
本身擁有Fork後的倉庫的讀寫權限；
能夠推送pull request給官方倉庫來貢獻代碼。

20.自定義GIT
在安裝Git一節中，咱們已經配置了user.name和user.email，實際上，Git還有不少可配置項。
好比，讓Git顯示顏色，會讓命令輸出看起來更醒目：
$ git config --global color.ui true
這樣，Git會適當地顯示不一樣的顏色，好比git status命令：
git-color
文件名就會標上顏色。
咱們在後面還會介紹如何更好地配置Git，以便讓你的工做更高效。

 

21.忽略特殊文件
有些時候，你必須把某些文件放到Git工做目錄中，但又不能提交它們，好比保存了數據庫密碼的配置文件啦，等等，每次git status都會顯示Untracked files ...，有強迫症的童鞋內心確定不爽。

好在Git考慮到了你們的感覺，這個問題解決起來也很簡單，在Git工做區的根目錄下建立一個特殊的.gitignore文件，而後把要忽略的文件名填進去，Git就會自動忽略這些文件。

不須要從頭寫.gitignore文件，GitHub已經爲咱們準備了各類配置文件，只須要組合一下就可使用了。全部配置文件能夠直接在線瀏覽：https://github.com/github/gitignore

忽略文件的原則是：
忽略操做系統自動生成的文件，好比縮略圖等；
忽略編譯生成的中間文件、可執行文件等，也就是若是一個文件是經過另外一個文件自動生成的，那自動生成的文件就不必放進版本庫，好比Java編譯產生的.class文件；
忽略你本身的帶有敏感信息的配置文件，好比存放口令的配置文件。

舉個例子：
假設你在Windows下進行Python開發，Windows會自動在有圖片的目錄下生成隱藏的縮略圖文件，若是有自定義目錄，目錄下就會有Desktop.ini文件，所以你須要忽略Windows自動生成的垃圾文件：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
而後，繼續忽略Python編譯產生的.pyc、.pyo、dist等文件或目錄：
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
加上你本身定義的文件，最終獲得一個完整的.gitignore文件，內容以下：
# 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，就完成了！固然檢驗.gitignore的標準是git status命令是否是說working directory clean。

使用Windows的童鞋注意了，若是你在資源管理器裏新建一個.gitignore文件，它會很是弱智地提示你必須輸入文件名，可是在文本編輯器裏「保存」或者「另存爲」就能夠把文件保存爲.gitignore了。

有些時候，你想添加一個文件到Git，但發現添加不了，緣由是這個文件被.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.
若是你確實想添加該文件，能夠用-f強制添加到Git：
$ git add -f App.class
或者你發現，多是.gitignore寫得有問題，須要找出來到底哪一個規則寫錯了，能夠用git check-ignore命令檢查：
$ git check-ignore -v App.class
.gitignore:3:*.class App.class
Git會告訴咱們，.gitignore的第3行規則忽略了該文件，因而咱們就能夠知道應該修訂哪一個規則。

小結
忽略某些文件時，須要編寫.gitignore；
.gitignore文件自己要放到版本庫裏，而且能夠對.gitignore作版本管理！

22.配置別名
有沒有常常敲錯命令？好比git status？status這個單詞真心很差記。
若是敲git st就表示git status那就簡單多了，固然這種偷懶的辦法咱們是極力同意的。
咱們只須要敲一行命令，告訴Git，之後st就表示status：
$ git config --global alias.st status
好了，如今敲git st看看效果。

固然還有別的命令能夠簡寫，不少人都用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參數是全局參數，也就是這些命令在這臺電腦的全部Git倉庫下都有用。

在撤銷修改一節中，咱們知道，命令git reset HEAD file能夠把暫存區的修改撤銷掉（unstage），從新放回工做區。既然是一個unstage操做，就能夠配置一個unstage別名：
$ git config --global alias.unstage 'reset HEAD'
當你敲入命令：
$ git unstage test.py
實際上Git執行的是：
$ git reset HEAD test.py
配置一個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"
來看看git lg的效果：
git-lg
爲何不早點告訴我？別激動，咱不是爲了多記幾個英文單詞嘛！

配置文件
配置Git的時候，加上--global是針對當前用戶起做用的，若是不加，那隻針對當前的倉庫起做用。
配置文件放哪了？每一個倉庫的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]後面，要刪除別名，直接把對應的行刪掉便可。
而當前用戶的Git配置文件放在用戶主目錄下的一個隱藏文件.gitconfig中：
$ cat .gitconfig
[alias]
co = checkout
ci = commit
br = branch
st = status
[user]
name = Your Name
email = your@email.com
配置別名也能夠直接修改這個文件，若是改錯了，能夠刪掉文件從新經過命令配置。

小結
給Git配置好別名，就能夠輸入命令時偷個懶。咱們鼓勵偷懶。

 

23.搭建Git服務器
在遠程倉庫一節中，咱們講了遠程倉庫實際上和本地倉庫沒啥不一樣，純粹爲了7x24小時開機並交換你們的修改。
GitHub就是一個免費託管開源代碼的遠程倉庫。可是對於某些視源代碼如生命的商業公司來講，既不想公開源代碼，又捨不得給GitHub交保護費，那就只能本身搭建一臺Git服務器做爲私有倉庫使用。

搭建Git服務器須要準備一臺運行Linux的機器，強烈推薦用Ubuntu或Debian，這樣，經過幾條簡單的apt命令就能夠完成安裝。

假設你已經有sudo權限的用戶帳號，下面，正式開始安裝。
第一步，安裝git：
$ sudo apt-get install git
第二步，建立一個git用戶，用來運行git服務：
$ sudo adduser git
第三步，建立證書登陸：
收集全部須要登陸的用戶的公鑰，就是他們本身的id_rsa.pub文件，把全部公鑰導入到/home/git/.ssh/authorized_keys文件裏，一行一個。
第四步，初始化Git倉庫：
先選定一個目錄做爲Git倉庫，假定是/srv/sample.git，在/srv目錄下輸入命令：
$ sudo git init --bare sample.git
Git就會建立一個裸倉庫，裸倉庫沒有工做區，由於服務器上的Git倉庫純粹是爲了共享，因此不讓用戶直接登陸到服務器上去改工做區，而且服務器上的Git倉庫一般都以.git結尾。而後，把owner改成git：
$ sudo chown -R git:git sample.git
第五步，禁用shell登陸：
出於安全考慮，第二步建立的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，由於咱們爲git用戶指定的git-shell每次一登陸就自動退出。
第六步，克隆遠程倉庫：
如今，能夠經過git clone命令克隆遠程倉庫了，在各自的電腦上運行：
$ git clone git@server:/srv/sample.git
Cloning into 'sample'...
warning: You appear to have cloned an empty repository.
剩下的推送就簡單了。

管理公鑰
若是團隊很小，把每一個人的公鑰收集起來放到服務器的/home/git/.ssh/authorized_keys文件裏就是可行的。若是團隊有幾百號人，就無法這麼玩了，這時，能夠用Gitosis來管理公鑰。
這裏咱們不介紹怎麼玩Gitosis了，幾百號人的團隊基本都在500強了，相信找個高水平的Linux管理員問題不大。

管理權限
有不少不但視源代碼如生命，並且視員工爲竊賊的公司，會在版本控制系統裏設置一套完善的權限控制，每一個人是否有讀寫權限會精確到每一個分支甚至每一個目錄下。由於Git是爲Linux源代碼託管而開發的，因此Git也繼承了開源社區的精神，不支持權限控制。不過，由於Git支持鉤子（hook），因此，能夠在服務器端編寫一系列腳原本控制提交等操做，達到權限控制的目的。Gitolite就是這個工具。
這裏咱們也不介紹Gitolite了，不要把有限的生命浪費到權限鬥爭中。

小結 搭建Git服務器很是簡單，一般10分鐘便可完成； 要方便管理公鑰，用Gitosis； 要像SVN那樣變態地控制權限，用Gitolite。