git很好用，但我很懒
在上家公司的时候，养成了使用git管理项目的好习惯。主分支、版本分支各个RC和Rease版本，每个patch都记录得很得当。所以几乎发布了两年，只出过一二次patch少打的情况，且是因为patch久远，测试时是正好完美避开了bug。
自从开始创业，自己一个人就是团队。号称一个人干了一个团队干的活，基本框架、API框架、小程序、VUE基础的管理平台、VUE基础的合作伙伴平台、Dockefile、Docker编排、Thrift为基础的RPC等等，这些模块加起来有将近10个，也都是一个人一个月完成。
问题很大，我很无奈，但却不是无辜
说到这里我自认为还对得起这10年的工作经验。但是，昨夜的一场发布，让我知道，我还是会犯错，且是一个轻敌的错。因为一个人开发，所以习惯了commit时只用最新版，所以发布时没有关心版本问题。但是昨天是两个版本修选上线，系统是有点不同的，不同有二：
1、主版本（备用版本）没有使用docker、没有使用thrift
2、主版本都使用的是单机配置
很遗憾，我没有给主版本打tag，可以说我自己都不知道是从哪个commit开始的。
因为我认为，我发布的分支版本一定没有问题，并且我准备将此分支版本做主版本。
开始一切顺利，正是我想想的那样。。。
大概晚上8：30时，发布完成，一切就绪；运行也Okay，突然发现，各rpc之间的调用是非常慢的。（请原谅我过早的上RPC，这主要是为了下个月加服务器准备的）
原本我开发的机器并没有线上机器性能好，但绝对不会卡！
怎么办，只能用备用版本，去掉RPC,这时我傻了，因为备用版本没有打tag，没有分支都是在主分支上的一个个commit。但是已经有用户支付成功，但订单被会滚了（因为我们的业务特殊，原本都是早上发布，昨夜因为晚上要运行重要程序且需要在10点前结束）。
只能找commit，重打tag，重建分支了
还算运气好，花了20分钟找到了commit位置，输入了一堆的指令，终于把tag给打上了。
git checkout 34243211322131 -b release-2.0RC
git push origin release-2.0RC
...
git tag release-2.0RC001
git push --tags
git cherry-pick ...
git push origin master --tags总共花了一个小时的时间来发布。
这还是建立在我有很好的commit习惯的情况下（当然，这个习惯中的commit 信息被我给吃了）
吃一堑，长一智吧，以后还是好好按照git的正常使用方法来使用，发布的时候就不会措手不及了！