【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
一、 概要
基于git的版本管理规范及流程，主要包括：代码库分类、代码管理模式、代码管理规范、代码分支创建合并流程。
二、 代码库分类
根据代码库分布的位置及作用，分为以下三类：
- 主库：位于在线git仓库，所有开发的代码最终都要合到主库；
- 需求代码库：每次根据需求从主库fork出来，位于在线git仓库。每个开发人员开发的代码，由个人工作库push到对应的需求代码库；
- 个人工作库：位于每个开发人员的云桌面，从需求代码库clone到云桌面。每个开发人员开发的代码，先commit到个人工作库，再由个人工作库push到需求代码库；
三、 代码库管理模式
本系统采用分支开发+主干发布模式：
所有的代码提交都在分支上操作，系统上线需要构建Release版本时，需要将代码合并到主干上面，平常开发都是在分支上进行，可保证主干代码始终可用；
需求分支合并到主干上线完成后，由代码管理与技术经理、需求负责人确认需求完成之后一个月后删除该分支，后续变更需求需要创建新的branch；
四、 代码管理规范
- 原则上代码的开发提交，必须通过创建分支进行开发，特殊情况除外（sonar bug）；
- 主分支为生产环境分支，除特殊情况（修复bug），禁止在主干分支上进行开发；
- 需求分支（分支名称由管理员根据需求内容进行创建）为开发分支，一般作为主要的代码提交分支；
- 其他分支，为特殊情况建立的分支，命名应带有分支相关信息；
- 在代码开发阶段，代码的提交尽量独立化，也就是功能模块尽量细分，每个开发负责一个模块，尽量不要修改其他成员模块代码；
- 多人协作时，需要创建一个需求分支，然后一起在需求分支里协作开发，防止代码回溯。禁止各自开发，然后线下发送文件合并；
- 代码提交前，必须先进行更新代码（git pull），对于有冲突的文件，必须要进行对比，确认所有修改都是自己修改的，然后在进行提交，防止代码回溯（即别人的代码被覆盖）；
- 代码出现冲突时，必须要与冲突代码提交者进行确认冲突内容，双方确认无误方可处理；
- 提交代码必须先compare，确认没有冲突之后再进行pull，然后再将本地的代码进行commit，最后进行push；
- 代码提交时，必须描述清楚做了什么，提交动作有add、update、remove，提交格式为[动作]+[操作的模块信息]+[操作描述信息]，例如：‘将人员管理精确查询修改为模糊查询’，每次提交尽量一个动作，多个动作请多次提交；
- 在git中，默认空目录不会提交，如果某个空目录想提交到版本库，需要在该目录下新建一个deleteme.txt的空白文件；
五、 代码分支创建合并流程
- 分支创建：管理员根据需求文档、概要设计以及相关的会议评审纪要才能创建需求开发分支；
- 分支合并：需求开发分支在测试环境发布、测试通过且sonar扫描bug修复完成之后，再将开发分支合并到主干，主干发布到测试环境，复测通过之后才算合并完成；
- 分支删除：在需求上线完成一个月之后，管理员与需求、技术负责人确认分支是否删除之后，删除该需求分支；
来源：oschina
链接：https://my.oschina.net/u/2968081/blog/3147025