代码提交规范 && 升级调整
本系列想跟大家分享一下我近一年的管理经验，分享一下我们团队的一年走来的优化之路「非技术」，让大家少踩坑，以及如何协作，管理者容易遇到的问题，以及技术上，工作上，如何与同事沟通、跨部门如何沟通有效率、如何分组、站会有没有用？ 等等，一年到头，想和大家交流一下经验。
背景
项目早期
不管前端还是后端，项目早期，我们是有 master 被保护分支，以及 dev 测试分支的，我们的提交流程是：所有人往 dev 合并代码，进行测试封版，测试通过直接把 dev 合并到 master 进行升级。随之而来发现了问题：
项目中期
我们不能保证 dev 上的代码全部测试通过，因为没有充足的测试时间，而且不断有新的提交涌入，dev 直接合并到 master 肯定是不够稳妥的，这样的 dev 没有任何意义，随着研发任务强度越来越高，索性废弃了 dev ，直接合并到 master ， master 分支做持续集成到测试环境，每周二升级生产环境。每周三打 TAG，期间有迭代直接提交，直到下周二继续升级，如果非常紧急，那就基于 git tag 基础上修改，提交，升级生产。
反思
好景不长，随着研发任务的进一步提升，问题接踵而来，新业务测试不熟悉，测试时间长，每周二11点还没测试完毕，甚至每周二晚9点多才发现某某功能需求有问题，还会有其他小组影响另外小组的进度（关于小组以后单独讲）。这让研发叫苦不迭。每周二的 升级日 变成了 “加班日” ，虽然每周只有一天，且第二天可以晚点来上班，但是连续两周下来，还是有个别同事出现了严重的负面情绪，怕影响其他人，所以需要迅速解决这个问题。大刀阔斧的调整流程！
参考资料
上文资料请大家简单看一看,我们经过讨论做了调整，但是基本原理不变。
调整
研发 随写随提，测试 随提随测，运维 随测随更。随时测试，随时更新，随时升级生产环境。
协商一个时间点，比如每天 19:30，过了 19:30 的需求、bug，明天在调整，尽早回家休息。
研发职责
研发负责人还是像以前一样，多建立一个 dev 分支，用于测试，这里对 dev 的功能做下说明:
dev 分支
dev 分支就是测试环境，我们把 CI 从 master 换成 dev
这个分支，不需要有权限控制，研发根据 禅道 或者 card 上的任务，从 master check 出一份分支
以 禅道 bug http://xx.104.96.233:60888/zentao/bug-view-11568.html 为例
-
我们为分支命名为： fix-bug-11568
-
修复 BUG
-
commit 代码写好 msg:fix xxx ， merge 到 dev 「fix-bug-11568 分支此时不要删除」
-
通知相关人士进行测试
-
测试失败「打回重新提交」，测试成功点击「关闭」通知研发可以了。
-
研发发起 PR 从「 fix-bug-11568 分支 （注意！不是 dev）」到 Master 后 「 fix-bug-11568 」由管理员合并并删除
-
此时 Master 随时可以升级到生产。
这样会比较麻烦，于是参考 闲鱼技术 我们也自研了一套流程工具，具体下次专门出篇文章讲讲。
研发禁止的
- 禁止从 dev 分支 check 代码，因为你要保证合并到 master 的只有你自己的，没有其他人没测试的，如果从 dev check 代码，合并到 master 相当于 dev 合并到 master。
- 禁止 merge dev 到 master ，这样 dev 分支没意义。
一些问题
大家可能觉得极为繁琐，比如：
- 需要根据 ISSUES 创建分支名称
- 需要通知测试测试
- 测试需要通知研发成功/驳回 等等。
研发会写 devops 工具确保大家能逐渐自动化，只是需要一些时间。可以通过一些 CLI + git 钩子/ 禅道 发送邮件等等，达到减少沟通成本。
测试职测
目前测试的同事需要收到解决的问题快速进行测试，快速通知研发结果。等待之后的邮件提醒。
运维职测
原有的 CI 脚本有小调整 (dev)，生产升级也有小调整 (不能从 qmenhu 直接拽包)
调整服务器 Git hooks ，当有 push 或 merge 请求，查询 BUG 编号，是否已经关闭，关闭的 bug 或 feature 才可以 review -> merge，否则 服务器直接驳回。
总结
一切为了团队更高效的解决问题，有充分的的个人时间。
后续任务
--- git hooks 详情 ---
工具
我把工具发布在 npm 上了，没有开源，需要的可以借鉴一下，下次讲的时候，我会抽出一些通用的开源，现在先让内部 “打磨一下”
预览
以后单独抽一章讲下，代码很简单（5个小时工作量），主讲思路，以及如何才能做好简单的 devops，节省所有人的时间。
