blog.csdn.net-----本人CSDN原创博客链接
目的
-
最大程度降低多人合作时的分支冲突。
-
减少因合并导致bug重复出现。
-
避免因产品发布计划调整造成不必要的工作。
版本号管理
-
重大变更升级主版本号（例如硬件版本迭代）：1.0.0->2.0.0
-
每次功能更新递增次版本号 ：1.0.0->1.1.0
-
Bug修复只增加修订号：1.0.0->1.0.1
代码提交规范
【修改内容】：
-
新增xxxxx功能；
-
调整xxxxx逻辑；
-
去除xxxxx功能
-
修复xxxx问题，原因xxxx，解决措施xxxx；
-
修复Bug：xxxxxx
【影响范围】：
描述本次修改提交可能影响到的功能和模块
备注：
-
代码勤提交，进行完一个重大逻辑调整，开发完一个新功能，修复完一个重大问题都需要进行代码提交；
-
修复Bug建议按功能模块进行修复，修复完后进行阶段性提交；
分支管理
分支分类
master
对应最新版本生产环境的的代码，可随时部署生产环境。该类型分支受权限保护，只有管理员由合并权限。分支名称默认为master。
release
对应计划发布的版本代码，可随时部署测试环境。该类型分支受权限保护，只有管理员由合并权限。分支名称默认为release。
feature
日常功能开发使用，对应各个功能模块。分支命名规则为feature-功能名称-负责人。
hotfix
用于修复master分支上的bug，分支名称规则为hotfix-bugId-负责人。
代码管理流程
新增功能流程
feature合并到master后，需要删除feature分支
测试环境修复bug流程
生产环境修复bug流程
多feature情况下存在依赖关系的处理
规范
-
项目需要根据项目需求划分功能，根据功能创建不同的feature分支。如功能之间存在依赖还需要明确分支之间的依赖关系。
-
feature分支只能从master和依赖的feature分支拉取代码，禁止从release和非依赖feature分支拉取分支。
-
hotfix分支只能从master分支拉取代码，禁止从其他类型分支拉取代码。
-
当release分支合并到master分支后，需要根据最新的master新增一个tag存档，同时删除已经合并的feature分支。
-
release分支的代码只可用于测试，不可部署到生产。
-
master分支的代码可用于生产。
-
禁止除了release之外的分支合并到master。
-
请不要提交与代码无关的文件，如由IDEA生成的.iml文件、obj或者build目录等。
-
当无法确定如何操作时，请与大家讨论。
-
每个人只允许修改自己的分支，或者主动合并其他分支的修改到自己的分支，不允许擅自修改他人分支，有需要可以基于别人的分支，新建分支出来进行修改和验证。
-
协同开发时，各分支的修改可以通过提交“merge请求”由项目负责人合并到release分支。
基础代码管理建议
一些通用代码可以抽离成通用的框架或者组件，然后单独项目来维护，以此降低因基础代码变动而导致不必要的工作量。