git tag

　　平常在翻看书籍的时候，是不是经常的使用书签记录当前阅读的地方，方便下次接着阅读。其实，在git中，也有个类似的功能，就是tag。

场景

　　在手机app开发中，如果你没有使用热修复等功能，那么每次线上出现严重bug需要fix的时候，你就得check出发布的版本，然后修改bug之后发包上线，这是一个很麻烦的操作。
　　每个人的处理方式不一样，有些人会把每次发版的版本单独做一个分支，这是一个方法。但是版本迭代如此之快，岂不是会有若干个分支存在，你肯定会说，等后续版本发布之后就可以将前面的分支删除掉了。那么，这个时候，倘若产品需要以前的版本你该如何(我还真就遇到过)？
　　实际上我们通过tag来管理每个版本十分方便。

举个栗子

第一版开发

　　下面我们开始第一个版本的开发，提交若干个commit。

$ vim a.txt
$ git add .
$ git commit -m "第一次提交"
$ vim b.txt
$ git add .
$ git commit -m "第二次提交"
$ git push origin master

　　这个时候第一个版本迭代完成，我们可以发布上线。在发布上线的时候，我们使用tag记录当前版本最后的commit。

$ git tag --list
$ git tag -a v1.0.0 -m "版本1.0.0上线"
$ git push origin v1.0.0

　　这个时候git仓库的commit记录如下。

第二版迭代

　　发布上线之后，我们开始了第二版的迭代，再提交若干个commit。

$ vim c.txt
$ git add .
$ git commit -m "第二版开发"
$ vim d.txt
$ git add .
$ git commit -m "第二版开发"
$ vim a.txt
$ git add .
$ git commit -m "第二版开发"

fix bug

　　这个时候，由用户反馈某个功能出现问题，需要修复重新打包上线。这个时候我们需要将tag来出来，然后修复bug。

$ git checkout v1.0.0 -b bugfix

　　这个时候我们将之前tag所对应的commit单独checkout出来为一个分支。然后在这个分支上进行bugfix。

$ vim a.txt
$ git add .
$ git commit -m "bug fix"

　　这个时候bug fix完成，然后我们需要将bug fix之后的代码merge到主分支，以保证主分支的代码也是bug fix的。这里a.txt文件是同时修改了，所以会有冲突，如果你知道如何解决冲突，请看git rebase/merge。

$ git checkout master
$ git merge bugfix
$ git add .
$ git commit -m "v1.0.0bug fix"

　　这个时候git仓库的commit是这个样子的。

重新打入tag

　　千万要记住，你bugfix之后要会从新打入tag，防止出现其他的问题。

$ git checkout bugfix
$ git tag --list
$ git tag -a v1.0.1 -m "v1.0.1 bug fix"
$ git push origin v1.0.1

　　余生没那么长，不要一味的付出去惯那些得寸进尺的人，请忠于自己，活得像最初的模样！