共计 861 个字符，预计需要花费 3 分钟才能阅读完成。
为什么要应用 git 标签
随着大规模微服务开发的倒退，各个微服务之间的相互依赖总会思考版本的问题。以前咱们采纳不同的分支来临时解决这个问题，然而对分支的迭代偶然会引入不兼容的更改，产生不可意料的问题。
应用 git 标签，能够将咱们依赖的某个微服务的版本限定到某个确定的 commitID 而不是某个常常会迭代的分支。配合语义化版本的引入，咱们能够轻松的解决版本依赖的问题
如何给某个 commentID 打 tag
| 命令 | 阐明 |
|---|---|
| git tag | 查看所有标签, 按 q 退出 |
| git tag -l <tagname> | 查看指定标签 |
| git tag <tagname> | 在以后分支的最新 HEAD 上创立轻量级标签：tagname |
| git tag <tagname> <commitID> | 为对应的某个 commitID 打标签 |
| git tag -a <tagname> -m <comment> | 为标签 tagname 减少阐明 comment |
| git show <tagname> | 查看标签：tagname 的内容 |
| git tag -d <tagname> | 删除标签：tagname |
推送标签内容到远端
| 命令 | 阐明 |
|---|---|
| git push origin –tags | 推送所有标签到远端 |
| git push origin <tagname> | 推送指定标签到远端 |
| git push origin :refs/tags/<tagname> | 删除远端指定标签 |
如何疾速回滚到某个 tag
$git reset <tagname> 如何疾速切换到某个 tag
$git checkout <tagname>为什么网上的很多开源我的项目只有 master 分支呢
版本治理能够借助 git 的 tag 来实现。然而，在开发过程中，不可能每次批改都打标签而后公布。
理论开发中，个别会有一个 dev 分支，作为开发版本分支。在没有实现此次开发工作前，所有的代码都是合并到 dev 分支。
当实现了开发工作，管理者会将 dev 分支合并到 master 分支，而后删除 dev 分支，并且通过打标签来公布版本。
这就是为什么很多放弃保护的大型开源我的项目只有 master 分支的起因。
参考：https://segmentfault.com/a/11…
正文完