【GIT-3】GIT 的基礎教程 分支管理 fixbug分支 Featur 衝突處理 標籤管理 操做

 

 

【轉載請註明出處！http://my.oschina.net/u/2337744/】

分支就是科幻電影裏面的平行宇宙，當你正在電腦前努力學習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 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鼓勵大量使用分支。

 

▓▏合併分支的衝突處理▕▓：

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

準備新的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

# On branch master

# Your branch is ahead of 'origin/master' by 2 commits.

#

# Unmerged paths:

#   (use "git add/rm <file>..." as appropriate 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 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命令能夠看到分支合併圖。

▓▏分支管理策略▕▓：

一般，合併分支時，若是可能，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分支十分強大，在團隊開發中應該充分應用。

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

       

▓▏fixbug分支▕▓：

軟件開發中，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: 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-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 cc17032] 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 2 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(-)

$ git branch -d issue-101

Deleted branch issue-101 (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

# 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內容了：

$ git stash list

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

$ git stash apply stash@{0}

小結

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

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

▓▏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 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>強行刪除。

▓▏多人協做▕▓：

當你從遠程倉庫克隆時，實際上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: 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

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

$ git checkout -b dev origin/dev

如今，他就能夠在dev上繼續修改，而後，時不時地把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

你的小夥伴已經向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已經提示咱們，先用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分支的連接，根據提示，設置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

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

首先，能夠試圖用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，若是有衝突，要先處理衝突。

▓▏標籤管理▕▓：

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

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

▓▏建立標籤▕▓：

在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

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簽名。驗證簽名的方法比較複雜，這裏就不介紹了。

小結

命令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)

由於建立的標籤都只存儲在本地，不會自動推送到遠程。因此，打錯的標籤能夠在本地安全刪除。

若是要推送某個標籤到遠程，使用命令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>能夠刪除一個遠程標籤。

▓▏忽略特殊文件▕▓：

有些時候，你必須把某些文件放到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了。

小結

忽略某些文件時，須要編寫.gitignore；

.gitignore文件自己要放到版本庫裏，而且能夠對.gitignore作版本管理！

▓▏配置別名▕▓：

有沒有常常敲錯命令？好比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的時候，加上--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配置好別名，就能夠輸入命令時偷個懶。咱們鼓勵偷懶。

▓▏git刪除遠程文件夾或文件的方法▕▓：

git刪除遠程文件夾或文件的方法

因爲本地修改了文件夾大全名大小寫的緣由，同步到git上並不區分大小寫，形成了一些文件同步不了，因此要先把git遠程庫上文件夾刪除掉，而後再從新同步

以下，將指定的文件夾或者文件所有移除，可是本地文件還保留。

git rm -r -n --cached  遠程文件名      //-n：加上這個參數，執行命令時，是不會刪除任何文件，而是展現此命令要刪除的文件列表預覽。

 

git rm -r --cached 遠程文件名      //最終執行命令.

 

git commit -m"移除指定全部文件的版本控制"    //提交

 

git push origin master   //提交到遠程服務器