工作中发现旧代码需要优化，但是手上又有需求，该如何处理呢？规范化 Git commit message，让提交信息更有意义。
代码优化需求
代码具体哪些方面会存在优化
- 增强代码的健壮性
- 优化用户体验
- 提高页面渲染性能
- 优化代码结构
- 提高开发人员效率
对于代码优化需求的具体流程
- 梳理 CodeReview 后发现的问题，分析哪些问题需要进行修改和优化；
- 整理好每个修改点可能会导致的问题；
- 向项目经理、产品经理、测试等研发发送申请项目优化的排期邮件；
- 待排期确定后，再安排研发修改问题，避免提前修改，因为中间穿插的日常需求开发，有可能会导致后期合并代码带来的隐患；
- 经过测试检查无误后，再上线；
规范化 Git 提交
规范 git 提交：标识：内容，说明此次提交的目的
- feature：新功能
- fix：修补bug
- docs：文档
- style：格式，不影响代码运行的变动
- refactor：重构
- test：增加测试
- chore：构建过程或辅助工具的变动
通常我们可能会提交一些没有意义的 commit message，原因通常如下
- 当前分支开发到了一半需要紧急切换其他分支，如果不提交，可能不允许切换分支或者出现把当前的修改带到了新的分支的情况，所有先提交一个临时的，回头再次开发；
- 当前分支开功能开发完了，提交一版本，一会发现有问题，可能只是一行代码，在提交一次。来来回回提交了好几次代码；
针对这两种情况：
- 可以使用
git stash，去暂时保存，但不提交代码，等切换回分支的时候，再读取出来开发git stash apply； - 针对第二种情况已经提交了，这时候可以用
git commit--amend，撤销上一次提交到暂存区，并重新提交内容；
开发流程
开发流程优化
- 制定开发规范
- 梳理各个分支对应状态分布
- 制定项目开发流程
- 汇总项目调试方法
- 规范上线流程
- 优化评审机制
- 通过了每两周进行一次需求集体评审的制度。
- 对于紧急需求，根据其紧急程度评估是否单独组织评审。
- 推进新技术学习
- 推进视觉合作机制
- 推进版本迁移
- 排期规范化
- 紧急需求安排较为空闲研发支持；
- 不是特别紧急的需求安排下次排期；
- 对于线上问题，如果能够很快修复，一般跟随下一个上线需求一起上线；如果不能快速修复的，重新走排期。