2157 git tag //查看tag 2158 git tag test_tag c809ddbf83939a89659e51dc2a5fe183af384233 //在某個commit 上打tag 2159 git tag ... 2169 git push origin test_tag //!!!本地tag推送到線上 ... 2180 git tag -d test_tag //本地刪除tag 2181 git push origin :refs/tags/test_tag //本地tag刪除了，再執行該句，刪除線上tag
摘 自: https://blog.csdn.net/fuchaosz/article/details/51698896html
1 前言
本系列之因此取名」Git高級教程」，主要是教你們解決實際工做中遇到的問題，要求讀者會基本的Git用法和命令，請不要使用SourceTree這樣的工具，由於它讓你啥都不會、啥也不懂，git自己與Linux一脈相承，都是Linus torvalds寫的嘛，因此命令行纔是精髓。若是你還不會Git的話，強烈建議你學習廖雪峯的教程,簡單易懂：git
廖雪峯的Git教程github
博主也是從這兒入門的，既然有這麼好的教程，爲何還要寫這個系列的博客呢？很簡單嘛，這個教程只是入門教程，解決實際工做中遇到的問題仍是不夠的，因此博主專門寫Git高級教程，記錄如何解決實際工做中的問題。服務器
2 簡介
先提一個問題，若是線上版本遇到bug，老闆要求緊急修復這個bug，而後立刻發版本，但是這個時候咱們的代碼新功能已經開發了到一半了，不能回退，怎麼辦呢？svn
用過SVN的童鞋都知道，當一個版本發佈後，就要拉一個分支作備份，這樣之後線上版本出現緊急bug就能夠直接在分支上修復後，發版本，而後合併分支到主幹上。工具
如今咱們使用Git進行版本管理的時候，則只須要打一個標籤就行啦。post
3 Git與SVN區別
Git和SVN正好相反，git提倡開發時拉分支，各幹各的，相互獨立，發版本時打標籤；而svn呢，平時你們都在主幹上幹活，發版本時拉個分支，因此呢，svn常常會提交衝突，常常要合併代碼，只能先把本身的代碼備份，而後下載別人的，再合併。Git只須要合併一次就好了。學習
爲啥會這樣呢？由於SVN拉分支真的就是在磁盤上覆制一份代碼，速度天然是很慢的啦，因此你們都不喜歡拉分支，只有發版本時拉一下。而git呢，拉一個分支其實只不過是增長了一根指針而已，因此很快，發版本時打個標籤，其實只是取個別名而已，一樣很快。編碼
本文就講述如何經過標籤來修復緊急bug。url
4 環境搭建
咱們先來模擬開發中遇到的狀況，博主演示用的目錄是 e:\learngit
(1) 首先在e盤下建一個文件夾learngit, 而後打開GitBash，進入e:\learngit目錄，並初始化：
cd "e:\learngit"
git init
1
2
使用下面的命令，來設置你的用戶名和郵箱，這裏的用戶名和郵箱通常是你的github帳號:
git config user.name "xxxx"
git config user.email "xxx@xxx"
1
2
(2) 在leangit下新建一個文件a.txt,而後寫
第一次發版本
1
用下面的命令來提交：
git add a.txt
git commit -m "第一次發版本"
1
2
提交完畢，可使用下面的命令來查看提交的記錄:
git log
1
(2) 打標籤，發佈版本以後就要打標籤了,命令以下：
git tag -a v1.0 -m "v1.0版本發佈"
1
而後查看全部標籤用下面命令：
git tag
1
你也能夠查看某個標籤的詳情：
git show v1.0
1
上面是打標籤的時候寫的備註，下面是標籤記錄的那次提交的備註，其實標籤只是對某一次提交記錄起了一個別名而已，不要覺得經過標籤一下次就能拉取代碼。
(3) 在a.txt中增長一行」第二次發佈版本」，而後用
git add a.txt
git commit -m "第二次發佈版本"
1
2
命令提交，可是不須要打標籤。
(4) 在a.txt中再增長一行」第三次發佈版本」，而後用
git add a.txt
git commit -m "第三次發佈版本"
1
2
命令提交，也不須要打標籤，這樣咱們就模擬了在第一次發佈版本，打完標籤後，咱們向前繼續開發的過程，a.txt內容以下：
第一次發版本
第二次發版本
第三次發版本
1
2
3
用 git log命令查看，以下圖：
(5) 到此咱們就模擬完成了，這個時候第一次發的版本有個bug，要緊急修復，下面咱們來完成這個需求
5 經過標籤恢復代碼
(1) 查看標籤的詳情，找出打標籤的那次提交的commit id
git tag
git show v1.0
1
2
commit id這麼長記不住怎麼辦呢？別擔憂，咱們只須要記住前面幾位就能夠了，這裏咱們只取前6位：7441b8。Git會根據前面幾位自動識別的，固然，你的commit id跟個人確定是不同的。
(2) 版本回退
下面咱們就經過commit id回到發版本時候的代碼去嘍:
git reset --hard 7441b8
1
注意把7441b8換成你的commid id。回退完畢，再看a.txt:
第一次發版本
1
若是有亂碼的話，改爲以UTF-8無BOM格式編碼。看到沒，咱們又回到了第一次發版本時候的代碼，是否是有點小激動啊.
若是這個時候你立馬投入與bug的戰鬥，修改後發版本，那麼你就犯了嚴重的錯誤，由於你修改後的代碼是沒法與正在開發的版本合併噠，也就是說你的修改並不能加入現有的代碼。因此:
特別注意：經過標籤回退版本後，要立刻拉一個分支，而後當前主幹分支要當即回到原來的位置，不然正在開發的代碼可能白乾了，接着在剛拉的分支上修改bug，修改完畢合併到主幹上
(3) 拉取分支
回退版本後，當即拉取分支，這裏取名bugfix分支：
git checkout -b bugfix
1
如圖所示，咱們已經在bugfix分支上了：
查看全部分支請用命令：
git branch
1
(4) 主幹分支當即回到原來的位置
首先，請先回到主幹分支上：
git checkout master
1
回退版本須要commit id，向前進呢，一樣也是的。還記得我在第三次提交完畢後，用git log命令查看提交記錄嗎，如今咱們須要第三次提交的commit id，再用git log命令：
能夠看到只有第一次的提交記錄了，由於這個時候版本回退了git log是查不到第三次提交記錄的，怎麼辦呢，怎麼才能回去呢？
別急，這個時候，咱們用下面這個命令：
git reflog
1
看到了嗎，你全部的操做記錄都在這兒，這就是git，記錄操做。能夠看到第三次的commit id是 7358a51。回去嘍：
git reset --hard 7358a51
1
再看a.txt:
第一次發版本
第二次發版本
第三次發版本
1
2
3
回到最新的版本啦
(5) 切換到bugfix分支，修改bug
git checkout bugfix
1
這時a.txt只有一行文字，由於咱們的bugfix分支是回退版本到第一次提交時拉取的分支，接着咱們加一行」修復第一次發版本的緊急bug」:
第一次發版本
修復第一次發版本的緊急bug
1
2
接着用命令
git add a.txt
git commit -m "修復第一次發版本的緊急bug"
git tag v2.0
1
2
3
提交此次修改，修改完畢，再打個標籤，通常標籤的版本要升一級,這樣下次再出bug了，就直接從這兒改起，也就能夠在合併後直接刪除bugfix分支了
(6) 合併到主幹上
在bugfix分支上修復了緊急bug以後，就能夠發一個新的版本，以後就要把修復後的代碼合併到咱們的主幹上，否則下次發版本這個bug仍是存在的。合併用下面的命令:
git checkout master //先切換到主幹上
git merge bugfix //再合併修改bug的分支
1
2
這個時候，你能夠在內心默唸，神獸保佑，沒有衝突。然而這並無什麼卵用，你念或不念，衝突就在那裏，很少很多。這個時候能夠用git status 命令查看誰發生了衝突：
從上圖能夠看到兩個分支都修改了a.txt,這個時候再來看a.txt:
第一次發版本
<<<<<<< HEAD
第二次發版本
第三次發版本
=======
修復第一次發版本的緊急bug
>>>>>>> bugfix
1
2
3
4
5
6
7
其中<<<<<<Head到======這個是當前分支，也就是master分支的內容，從======到>>>>>>>bugfix，是bugfix分支的內容
修改衝突很簡單啦，把多餘的內容去掉就能夠了
第一次發版本
修復第一次發版本的緊急bug
第二次發版本
第三次發版本
1
2
3
4
提交代碼就解決衝突了
(7) 推送標籤到遠程
在實際開發中咱們都是關聯了遠程倉庫的，在提交完代碼後咱們通常用git push將代碼推送到遠程倉庫中，可是git push命令是不會推送標籤的，這點必定要注意
標籤必須手動推送到遠程倉庫
能夠用下面的命令一次推送全部標籤到遠程：
git push origin --tags
1
(8) 好了，到這裏咱們就完成了經過標籤修復線上版本的緊急bug，這個時候你就能夠刪掉本地分支bugfix了，可是不建議你這麼作，搞很差線上又出個bug，你就能夠直接接着改啦，反正是在本地的分支。
6 總結
總結一下，經過標籤修改bug的步驟以下：
主分支回退到打標籤的那次提交
拉取分支bugfix
主分支當即回到最新狀態
切換到bugfix分支，修改bug，發版本，打新標籤
合併bugfix分支到主幹上
手動推送標籤到遠程
7 轉載請註明來自「梧桐那時雨」的博客：http://blog.csdn.net/fuchaosz/article/details/51698896
Tips
若是以爲這篇博客對你有幫助或者喜歡博主的寫做風格，就給博主留個言或者頂一下唄，鼓勵博主創做出更多優質博客，Thank you.
---------------------
做者：fuchaosz
來源：CSDN
原文：https://blog.csdn.net/fuchaosz/article/details/51698896
版權聲明：本文爲博主原創文章，轉載請附上博文連接！
--------------------------------------------------
同大多數 VCS 同樣，Git 也能夠對某一時間點上的版本打上標籤。人們在發佈某個軟件版本（好比 v1.0 等等）的時候，常常這麼作。本節咱們一塊兒來學習如何列出全部可用的標籤，如何新建標籤，以及各類不一樣類型標籤之間的差異。
列出現有標籤的命令很是簡單，直接運行 git tag 便可：
$ git tag v0.1 v1.3
顯示的標籤按字母順序排列，因此標籤的前後並不表示重要程度的輕重。
咱們能夠用特定的搜索模式列出符合條件的標籤。在 Git 自身項目倉庫中，有着超過 240 個標籤，若是你只對 1.4.2 系列的版本感興趣，能夠運行下面的命令：
$ git tag -l 'v1.4.2.*' v1.4.2.1 v1.4.2.2 v1.4.2.3 v1.4.2.4
Git 使用的標籤有兩種類型：輕量級的（lightweight）和含附註的（annotated）。輕量級標籤就像是個不會變化的分支，實際上它就是個指向特定提交對象的引用。而含附註標籤，其實是存儲在倉庫中的一個獨立對象，它有自身的校驗和信息，包含着標籤的名字，電子郵件地址和日期，以及標籤說明，標籤自己也容許使用 GNU Privacy Guard (GPG) 來簽署或驗證。通常咱們都建議使用含附註型的標籤，以便保留相關信息；固然，若是隻是臨時性加註標籤，或者不須要旁註額外信息，用輕量級標籤也沒問題。
建立一個含附註類型的標籤很是簡單，用 -a （譯註：取 annotated 的首字母）指定標籤名字便可：
$ git tag -a v1.4 -m 'my version 1.4' $ git tag v0.1 v1.3 v1.4
而 -m 選項則指定了對應的標籤說明，Git 會將此說明一同保存在標籤對象中。若是沒有給出該選項，Git 會啓動文本編輯軟件供你輸入標籤說明。
可使用 git show 命令查看相應標籤的版本信息，並連同顯示打標籤時的提交對象。
$ git show v1.4
tag v1.4
Tagger: Scott Chacon <schacon@gee-mail.com>
Date: Mon Feb 9 14:45:11 2009 -0800
my version 1.4
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch 'experiment'
咱們能夠看到在提交對象信息上面，列出了此標籤的提交者和提交時間，以及相應的標籤說明。
若是你有本身的私鑰，還能夠用 GPG 來簽署標籤，只須要把以前的 -a 改成 -s （譯註： 取 signed 的首字母）便可：
$ git tag -s v1.5 -m 'my signed 1.5 tag' You need a passphrase to unlock the secret key for user: "Scott Chacon <schacon@gee-mail.com>" 1024-bit DSA key, ID F721C45A, created 2009-02-09
如今再運行 git show 會看到對應的 GPG 簽名也附在其內：
$ git show v1.5
tag v1.5
Tagger: Scott Chacon <schacon@gee-mail.com>
Date: Mon Feb 9 15:22:20 2009 -0800
my signed 1.5 tag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEABECAAYFAkmQurIACgkQON3DxfchxFr5cACeIMN+ZxLKggJQf0QYiQBwgySN
Ki0An2JeAVUCAiJ7Ox6ZEtK+NvZAj82/
=WryJ
-----END PGP SIGNATURE-----
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch 'experiment'
稍後咱們再學習如何驗證已經簽署的標籤。
輕量級標籤實際上就是一個保存着對應提交對象的校驗和信息的文件。要建立這樣的標籤，一個 -a，-s或 -m 選項都不用，直接給出標籤名字便可：
$ git tag v1.4-lw $ git tag v0.1 v1.3 v1.4 v1.4-lw v1.5
如今運行 git show 查看此標籤信息，就只有相應的提交對象摘要：
$ git show v1.4-lw
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch 'experiment'
可使用 git tag -v [tag-name] （譯註：取 verify 的首字母）的方式驗證已經簽署的標籤。此命令會調用 GPG 來驗證簽名，因此你須要有簽署者的公鑰，存放在 keyring 中，才能驗證：
$ git tag -v v1.4.2.1 object 883653babd8ee7ea23e6a5c392bb739348b1eb61 type commit tag v1.4.2.1 tagger Junio C Hamano <junkio@cox.net> 1158138501 -0700 GIT 1.4.2.1 Minor fixes since 1.4.2, including git-mv and git-http with alternates. gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A gpg: Good signature from "Junio C Hamano <junkio@cox.net>" gpg: aka "[jpeg image of size 1513]" Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A
如果沒有簽署者的公鑰，會報告相似下面這樣的錯誤：
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A gpg: Can't check signature: public key not found error: could not verify the tag 'v1.4.2.1'
你甚至能夠在後期對早先的某次提交加註標籤。好比在下面展現的提交歷史中：
$ git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function 4682c3261057305bdd616e23b64b0857d832627b added a todo file 166ae0c4d3f420721acbb115cc33848dfcc2121a started write support 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile 964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
咱們忘了在提交 「updated rakefile」 後爲此項目打上版本號 v1.2，不要緊，如今也能作。只要在打標籤的時候跟上對應提交對象的校驗和（或前幾位字符）便可：
$ git tag -a v1.2 9fceb02
能夠看到咱們已經補上了標籤：
$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5
$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Date: Mon Feb 9 15:32:16 2009 -0800
version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@gee-mail.com>
Date: Sun Apr 27 20:43:35 2008 -0700
updated rakefile
...
默認狀況下，git push 並不會把標籤傳送到遠端服務器上，只有經過顯式命令才能分享標籤到遠端倉庫。其命令格式如同推送分支，運行 git push origin [tagname] 便可：
$ git push origin v1.5 Counting objects: 50, done. Compressing objects: 100% (38/38), done. Writing objects: 100% (44/44), 4.56 KiB, done. Total 44 (delta 18), reused 8 (delta 1) To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5
若是要一次推送全部本地新增的標籤上去，可使用 --tags 選項：
$ git push origin --tags Counting objects: 50, done. Compressing objects: 100% (38/38), done. Writing objects: 100% (44/44), 4.56 KiB, done. Total 44 (delta 18), reused 8 (delta 1) To git@github.com:schacon/simplegit.git * [new tag] v0.1 -> v0.1 * [new tag] v1.2 -> v1.2 * [new tag] v1.4 -> v1.4 * [new tag] v1.4-lw -> v1.4-lw * [new tag] v1.5 -> v1.5
如今，其餘人克隆共享倉庫或拉取數據同步後，也會看到這些標籤。