每日思考-关于合并代码的一些思考

背景：
项目上因为合并代码出现过一些问题，甚至是线上事故，所以针对代码合并这件事情进行了一些思考，大概列出一些需要关注的点和流程。

合并原由

1. 合并的理由要清楚，是要做集成还是说要合二为一进行合并开发，最初的目的要简单清晰；

合并原则

1. 合并原则：feature向test合并，feature正常来说不能合并到feature，feature的含义就是具有一种特性的分支，feature代码可以是一个大的需求，也可以是一个小的功能点，但test一般来说是集成测试分支，大家的feature分支可以合并到test分支进行集成；

合并流程

1. 合并前检查：要确认两支分支的正确性（合并者的代码是否已完全提交、无编译错误、名称正确），想一下可能存在的冲突及解决冲突的应对措施；
2. 合并时处理：主要是可能遇到代码冲突，如果有大量冲突需要提高注意力这时代码提交风险已增强，需要思考为什么会有大量代码冲突，考虑是否放弃本次合并，如果一定要合并，那一定要每个文件仔细对比进行合并，必要时可以找协助者；
3. 合并后检查：检查合并后编译是否正确、pom文件检查、检查本地服务启动是否ok、检查重要合并功能；
4. 合并后代码提交：合并了且冲突已解决，检查已完毕，这时就要将代码进行提交，切不要忘了；
5. 合并后服务部署：前面所有的工作都做完后其实还不能确保本次代码合并的正确性，要将新的代码部署到服务器上正常跑起来才算ok，部署前要重新打api包或sdk包。