当下对于代码的管理, 主要采用 GitLab 或 GitHub, 然而使用 Git 进行代码管理过程中, 一般有四种开发模式, 分别为主干开发主干发布, 主干开发分支发布, 分支开发主干发布, 分支开发分支发布. 四种开发模式各有特色, 下面将从针对四种开发模式进行一一说明.
但是针对微服务体系下, 代码的管理, 一般建议采用分支开发主干发布.
1. 代码管理模式
1.1. 主干开发 + 主干发布模式
模式特点: 所有的操作都在主干上进行操作, 随着时间的演进, 代码只有一个版本, 任何修改, 均体现在主干上面, 开发过程比较简单.
操作权限: 该种模式对于开发人员与项目经理等在代码提交方面, 权限相同;
适用场景: 该种模式适用于团队规模较小, 业务模型明确, 且人员技能较高的开发团队.
1.2. 主干开发 + 分支发布模式
模式特点: 所有的操作都在主干上进行操作, 随着时间的演进, 代码具有多个版本, 运行多个版本可并行提供服务.
操作权限: 该种模式对于开发人员与项目经理等在代码提交方面, 权限相同;
适用场景: 该种模式适用于多版本并存, 但只维护一个版本的产品, 其他版本不进行维护的项目, 该种场景较少.
1.3. 分支开发 + 主干发布模式
模式特点: 所有的代码提交都在分支上操作, 随着时间的演进, 需要构建 Release 版本时, 需要将代码提交到主干上面, 平常开发都是在分支上进行, 好处可保证主干代码始终可用.
操作权限: 该种方式开发人员只具有开发分支权限, 无 master 权限, 代码的 merge 只能由项目经理或有权人完成;
适用场景: 该种模式适用于多功能并行开发, 按照业务特性或模块进行在分支进行开发, 然后在进行合并后进行 Release 构建发布, 业务场景较复杂, 且人员素质层次不齐, 需要代码 review.
1.4. 分支开发 + 分支发布模式
模式特点: 所有的代码提交都在分支上操作, 随着时间的演进, 需要构建 Release 版本时, 也是直接在分支上进行构建, 各分支独立演进, 与主分支关系不大, 是主干开发主干发布的一个组合使用.
操作权限: 该种方式开发人员与项目经理一样, 只具有分支上的操作权限, 不具有 master 权限.
适用场景: 该模式适用于需求群 / 项目群的方式进行开发, 大家公用同一个代码库, 然后共享部门基础代码, 然后各分支独立进行演进.
2. 代码管理规范
无规矩不成方圆, 微服务架构下, 代码的管理一般采用 Git 进行管控, 因此, 在使用 Git 进行版本控制时, 应遵循一些原则及规范.
2.1. 代码管理原则
代码管理的原则, 用于确保代码管理过程中不出现原则性错误, 出现原则性错误, 则会出现许多无用的操作, 基本原则如下:
模式确实后, 必须严格遵循执行;
提交代码时, 禁止代码强制提交;
代码提交时, 必须进行注释说明;
代码提交时, 必须按照规范执行;
出现冲突时, 必须进行确认处理;
2.2. 代码管理规范
由于微服务一般建议采用分支开发主干发布, 因此, 本规范主要针对分支开发主干发布模式, 具体规范如下:
原则上代码的开发提交, 必须通过创建分支进行开发, 特殊情况除外(bug),review 同事有责任进行检查其他同事是否遵循分支规范;
代码提交前, 必须先进行更新代码(Git pull), 对于有冲突的文件, 必须要进行对比, 确认素有修改都是自己修改的, 然后在进行提交, 防止代码回溯(即别人的代码被覆盖);
review 同事遇到代码删除情况, 必须与开发确认, 是否为开发同事自己删除, 如果不是, 很可能就是代码回溯;
在代码开发阶段, 代码的提交尽量独立化, 也就是功能模块尽量细分, 每个开发负责一个模块, 尽量不要修改其他成员模块代码;
多人协作时, 需要创建一个远程分支, 然后一起在远程分支里协作开发, 防止代码回溯. 禁止各自开发, 然后线下发送文件合并;
代码提交前, 必须进行 Git pull, 且进行 Git diff 进行比对代码, 确保提交代码为自己修改内容, 防止出现代码回溯;
代码出现冲突时, 必须 要与冲突代码提交者进行确认冲突内容, 双方确认无误方可处理;
主分支 (master) 为生产环境分支, 除特殊情况(修复 bug), 禁止在 master 分支上进行开发;
代码提交时, 必须描述清楚做了什么, 提交动作有 add,update,remove, 提交格式为[动作]+[操作的模块信息, 尽量详细到具体的类名方法名]+[操作描述信息], 例如: Git commit -m 'update aa.java findByName 将精确查询修改为模糊查询', 每次提交尽量一个动作, 多个动作请多次提交;
在 Git 中, 默认空目录不会提交, 如果某个空目录想提交到版本库, 需要在该目录下新建一个 deleteme.txt 的空白文件;
开发分支 (developer) 为开发分支, 一般作为主要的代码提交分支;
修复分支为修复 bug 分支, 命名格式为 bugfix-{date}, 修复分支用于主要分支的 bug 修复工作;
功能分支为新增功能分支, 命名格式为 feature-{message}, 可合并到 developer 分支;
其他分支, 为特殊情况建立的分支, 命名应带有分支相关信息;
来源: https://www.cnblogs.com/pengteng/p/10923613.html