前几天放放做了一个让人崩溃的操作。
放放的公司的项目有两个主要的分支一个是master，一个主分支面向生产环境，一个dev面向开发和测试环境，一旦有人发布功能都会合dev分支，里面包含三种类型的代码，废弃代码，正在开发的功能代码，已经开发完的要发布的代码。
第一天：
放放一直以为的发布流程是自己从dev拉分支进行开发，然后发dev进行测试，最后dev发master上线。
实际的流程确实从master拉分支开发，然后合dev测试，最后自己分支合master上线。
第一天：
放放功能写完了，想合一下dev，到时候让大佬们直接dev合master放放就没事情了。于是做了下面这个操作
feature-charge# git merge dev
出现了13000多处修改和151个新增文件，放放懵逼了什么鬼？？？
我就该了十几个文件，为啥成这个样子？？？
放放一脸懵逼的继续merge解决冲突，合并了几个小时之后，终于弄完了。想着第二天就可以发布了。
第二天：
烬哥哥说放放提个mr到master,放放说不是dev发master吗？
？？？烬哥哥说提你的分支合master。
放放要把他的feature-charge分支合并到master分支上，结果merge request请求都提不了，放放感到无力，what?
文件修改数目过多，页面上处理不了，必须手动解决。
行吧，线下手动，解决了3个小时，越来越接近发布时间。MR交给烬哥哥，烬哥哥说放放你的分支，现在包含了没有正在开发功能的代码，和要发布的代码，还有废弃的代码，如果直接合并到master会造成主分支的污染，肯定是不行的。
放放很懵逼，合了三个多小时，结果一句不行。烬哥哥说道，你还记得哪几次提交是你的，放放在commit的时候提示信息给的不是很明确，而且混合了两个功能的代码，只能回答记得不清楚了。那只能diff了，重新拉取一个分支，然后diff你当前的分支来处理。
放放通过以前的记忆，一个类一个类的diff，diff了一个小时终于完成了。放放心理感觉，再也不瞎合分支了，要给自己的commit做好提示，凡事留一线，想好退路，且多想一步。
烬哥哥说：放放还得多学习。其实当时你面对这么那么多类的变动，完全不应该一条一条的修改，太耗时间了。更简单的方法是，进行reset代码，回到你merge dev 之前的代码，然后进行cherry pick，拼接你修改的几个commit就可以了，这样既迅速有快捷，高效做事，结果导向。
放放总结：
A: 如何避免自己功能分支爆炸？
Q: 如果发测试，在dev分支上merge自己分支的代码。这样自己的分支就不会污染。
A: 如何解决分支爆炸问题？
Q: 如果误merge，可以使用git reset --merge还原这次合并。
Q: 从干净的master分支上拉分支，和自己的功能分支diff。
A: 发布如何做代码回滚？
Q:标准方式，每次发布打tag，出现大问题，直接回滚版本，再发布。
