“ 使用Git进行版本控制时，为了保持代码库的整洁、易于维护，以及方便团队协作，制定的一系列使用Git的最佳实践和规范 ”
01
—
分支管理
- master
生产分支
发布到生产环境的分支, 只能从release合并
由管理员管控, 合并之后触发生产环境发布
- release
预生产分支
发布到UAT环境的分支, 从develop合并, 发布成功后, 合并到master分支
由管理员管控, 合并之后触发UAT环境发布
- develop
开分分支
发布到测试环境的分支, 从feature或hotfix分支合并, 迭代完成之后, 合并到release, 准备发布
由研发自行管理, 合并之后触发SIT环境发布
- feature
功能分支
根据需求命名, 比如 feature-xxx, 由开发从develop拉取分支, 完成功能开发之后,合并到develop
- hotfix
补丁分支
用于解决生产BUG, 从master拉取的分支, 解决完成之后, 合并到develop, 再进行下一轮生产迭代
tips: 通常我们在各自的feature-a, feature-b分支下开发, 在往develop合并代码时, 先从develop pull到自己的feature分支中, 再进行push
02
—
Tag管理
生产发布完成之后, release合并到master, 此时master为最新的生产代码, 同时再打一个tag, 命名为 tag-20220303, 记录每次的发布历史
03
—
提交规范
代码提交时的comment规范是为了保持代码提交记录的清晰、易读和一致性，让团队成员更好地理解代码的变更和目的。以下是一些常见的代码提交comment规范：
- 提交类型（Commit Type）：以简短的标识说明本次提交的类型，例如：
-
feat: 新功能（feature）
-
fix: 修复bug
-
docs: 仅文档更改
-
style: 不影响代码含义的变化（空白、格式、缺少分号等）
-
refactor: 既不修复bug也不添加功能的代码更改
-
perf: 提高性能的代码更改
-
test: 添加缺失的测试或更正现有的测试
-
chore: 不修改src或测试文件的其他更改
-
build: 影响构建系统或外部依赖关系的更改（例如：gulp，npm）
-
ci: 持续集成文件和脚本的更改
-
简洁明了：保持comment简洁明了，用一句话概括本次提交的目的。
-
句首大写：comment的首字母大写，使用英文句号结尾。
-
参考问题（Optional）：如果本次提交是为了解决某个问题（比如Bug或需求），可以在comment中引用相关问题的编号。
-
内容详细：如果需要，可以在comment中详细描述本次提交的内容、改动和影响。
-
避免无关内容：尽量避免提交无关的或临时性的comment。
例如：
feat: 添加用户登录功能新增了用户登录的功能，包括前端页面和后端API。解决了#123的问题。
fix: 修复用户列表页面样式问题修复了用户列表页面显示错位的问题，样式调整使用了flex布局。Fixes #456.
**注意，不同的团队和项目可能有自己的特定规范，最好和团队成员商讨并遵循团队统一的代码提交规范。使用良好的代码提交comment规范可以提高代码的可维护性和团队协作效率。**
> 本文使用 [文章同步助手](https://juejin.cn/post/6940875049587097631) 同步
