git管理规范

前言

现在公司，研发团队太过原始，遂作出一些努力。

如果文章对你有帮助的话，记得一键三连哟。有问题和疑惑的话也可以在评论区留言。我会第一时间回复大家，如果觉得我的文章哪里有知识点错误的话，也恳请能够告知，把错的东西理解成对的，无论在什么行业，都是致命的。

日常博客记录在语雀，欢迎关注 语雀文档。

1、基本要求

1. 每个项目建立单独的git库，必须写README文件，描述项目整体；
2. 新仓库只有master主分支和release预发布分支，并且都应受保护，开发人员不允许直接在上面进行开发，只有项目管理者才能操作；
3. master分支只接受release分支进行合并；
4. 提交分支时注明：动作类型（新增、修改、删除）+改动明细；
5. 版本号命名规则：xx.xx.xx (大版本.功能性扩展.缺陷修复) ；
6. 禁止把无关文件上传到git库，如：密钥、视频等，仅上传代码；
7. 每天上班前拉取一次远程代码，下班前至少提交一次代码。

2、分支规范

主分支

master：随时可供在生产环境中部署的代码 （生产环境）

release：保存当前稳定并且最新的分支（预发布环境）

辅助分支

  辅助分支主要用于新功能的并行开发、对生产代码的缺陷进行紧急修复工作等，合并master后应该及时删除，使得仓库的常设分支只有master和release。

(1) 功能分支feature_*

  用于开发新功能时所使用的feature分支，从master分支上面分出来的。开发完成后，合并到release分支，上线后，打上标签后，最后删除feature_*分支。

(2) 修补缺陷分支bug_*

  用于修正生产代码中的缺陷的bug分支，从master分支上面分出来的。修复结束后合并release分支（如遇release已有版本在预发布环境，可以申请直接合并master），上线后，打上标签后``，最后删除bug_*分支。

(3) 辅助分支命名规则：分支类型_时间_开发模块

  feature分支：feature_20220506_moduleName

  bug分支：bug_20220506_moduleName

3、commit 日志规范

  为了方便追溯，git提交尽量遵循单次提交的代码是一个相对完整的功能或修改（可以使用rebase合并提交记录），不要把对几个功能的修改一起提交，提交信息一定要认真填写！

参考ng的commitizen

1. type是commit的类型：
2. fix：修复 xxx bug
3. feat：新增xxx 功能
4. style：修改 xxx 样式文件
5. docs：变更 xxx 文档
6. test：增加测试
7. revert：使用revert撤销上一次的commit
8. reset：使用reset撤销上一次的commit

4、合并规范

1. 在feature分支上开发时，如果master分支有变动，比如别人的功能开发完成并上线，需要将完成的功能合并到自己的分支上，即需要将feature分支rebase（变基）到master分支，不要用merge；
2. 合并到release分支上的代码必须是完整可运行的；
3. 合并到master分支的代码必须经过严格测试后才能合并，并且打上对应的tag标签v1.0.0，参照版本号命名规则；
4. 合并到master和release分支，必须提交PR(Pull Request)操作。