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
如今，其余人克隆共享仓库或拉取数据同步后，也会看到这些标签。