产品发版，有效控制代码，保证产品质量的简单看法
基本背景
在产品发版前，研发人员都会经历产品测试与bug修复的一个阶段，在这个阶段里面我们会发现产品很多的bug，并且会多次更新代码；更新代码是为了解决bug,但是有缺陷的更新可能会造成更多的bug；除此之后，也有一些开发者可能会更新一些和本次发版无关的代码，本应该这些代码不应该提交的，但是如果提交了，可能会造成更多的不必要的问题。这些问题都很常见，也必须要解决。本文简单总结一下自己的经历，欢迎点评和指正。
主要角色
管理者：负责开发过程的管理，具有代码的管理权限，能够整体把握代码的质量。
开发者：开发人员，修复bug（或者是bug制造者，哈哈）
git分支
开发分支：日常开发使用的分支。
发版分支：确定本次产品发版使用的分支，由管理端创建和控制，代码是最稳定的。
发版修复分支：用来修复本次发版中bug的分支，先在本分支上提交测试，确实无误后合并到发版分支。
整体介绍
主要有3个方面，如下图：
发版前
在确认产品要发版，进入测试阶段的时候，由管理者从开发分支新创建出发版分支和修复分支。并且把发版分支进行保护，任何提交必须管理员审核提交。
发版中
发现bug以后，在修复分支中进行修改测试提交，确实无误后，提出请求合并到发版分支，然后再进一步测试，测试通过后再把发版分支中的代码及时合并到开发分支中。
在这个过程中，如果有一些非发版要求的代码更新，就直接更新到开发分支即可。
发版后
使用发版分支进行产品发版，修复分支可以删除。同时用发版分支打一个tag，然后其实这个本次发版分支也可以删除了，有tag即可。
几个关键问题
- 发版修复bug的任何代码都不要提交到开发分支，否则你可能需要把开发分支的代码合并到发版分支中，但是开发分支中的代码是不稳定的（可能会由其他非发版要求的代码更新），虽然合并的时候可以选择合并，但这个过程可能也会稍微麻烦。关键点在于一个团队中，可能一部分人负责本次发版，修复bug，一部分人负责下次发版的筹划，需要在开发分支更新代码。这个好像没法控制，只能由管理者告知开发者，在修复分支上面更新。
- 确认无误的bug修复，一定要及时合并到开发分支中，这个很重要。刚才说的步骤，修复的bug并没有在开发分支解决，所以开发分支一定是有问题。这里重点强调一个及时，假设过了很久，首先担心的是容易忘记，导致下次发版的时候出现同一个问题，浪费时间；另外一个是开发分支已经更新了大量内容，然后再合并的时候将会变得很复杂，合并不注意的话很容易把开发分支中的代码覆盖掉（亲身经历，不过时间不长，能够看见有哪些覆盖，可以手动处理）。
- 发版分支，严格控制代码更新，非bug更新或者重大调整，不能提交。