分支命名规范
Git分支命名规范可以根据具体的项目和团队的需要而有所不同，但是以下是一些常见的规范：
- 主分支（master/main）：这个分支通常是主要的稳定分支，它包含了当前生产环境的代码。在一些项目中，这个分支也被称为“main”。
- 开发分支（develop）：这个分支是开发人员用来合并所有的特性分支和bug修复分支的分支。它应该始终是最新的开发状态，并且也应该比主分支或稳定分支更频繁地进行更改。
- 特性分支（feature）：这些分支是用来开发新特性或功能的，通常命名为“feature/”，其中是特性名称的简短描述。
- 修复分支（fix）：这些分支用于修复已知的bug，通常命名为“fix/”，其中是bug的简短描述。
- 发布分支（release）：这些分支用于准备代码发布，例如进行代码打包，版本更新等。通常命名为“release/”，其中是该版本的版本号。
- 热修复分支（hotfix）：这些分支用于修复生产环境中出现的紧急bug。它们通常是从主分支或发布分支中创建的，然后在修复后合并回主分支和发布分支。通常命名为“hotfix/”，其中是bug的简短描述。
除了上述命名规范，还需要注意以下几点：
- 尽量使用简洁明了的命名方式，避免过长或过于复杂的名称。
- 统一命名方式，确保所有开发人员都能理解和遵守命名规范。
- 避免使用特殊字符和空格，以免在使用Git命令时出现问题。
总之，良好的分支命名规范可以让代码仓库更加规范、易于管理和维护，提高团队协作效率和代码质量。
| 分支类型 | 命名规范 | 用途 |
|---|---|---|
| 主分支（master/main） | master或main | 包含当前生产环境的稳定代码 |
| 开发分支（develop） | develop | 用来合并所有的特性分支和bug修复分支的分支，通常是最新的开发状态 |
| 特性分支（feature） | feature/ | 用于开发新特性或功能 |
| 修复分支（fix） | fix/ | 用于修复已知的bug |
| 发布分支（release） | release/ | 用于准备代码发布 |
| 热修复分支（hotfix） | hotfix/ | 用于修复生产环境中出现的紧急bug |
| 自定义分支 | 可根据项目需要自定义命名规范，但需要清晰明了 | 根据具体项目需要创建其他类型的分支，但需要清晰明了其用途和命名约定，以确保代码库的整洁性和可维护性。 |
代码提交规范
下面是归纳汇总的代码提交规范：
- 提交信息格式： 包括提交信息的标题和正文，其中标题应该简明扼要、能够概括本次提交的内容，正文则应该详细说明本次提交的修改和原因。
- 提交频率： 尽量避免频繁提交代码，应该在一定的时间间隔或者完成一定的工作量后再进行提交，以减少不必要的代码冲突和版本控制问题。
- 提交范围： 只提交与本次任务或者功能相关的代码，避免将不相关的代码混在一起提交。
- 提交顺序： 先提交修改的文件、再提交新建的文件，同时在提交前进行代码格式化、排版等操作，以保持代码的一致性和整洁性。
- 分支选择： 在提交代码前，应该选择正确的分支进行代码提交，避免将代码提交到错误的分支或者提交到不合适的分支上。
- 代码质量： 提交的代码应该符合一定的质量要求，包括编码规范、代码风格、注释规范等，以提高代码的可读性和可维护性。
- 版本号控制： 在代码提交时，应该遵守版本号的规范，包括MAJOR、MINOR、PATCH等版本号的更新规则。
- 提交记录管理： 为了方便团队成员查看和管理提交记录，应该对提交记录进行分类和整理，例如通过使用标签或者注释来标记不同类型的提交记录，或者通过使用Git log命令来查看和管理提交记录。
- 关注点分离原则： 代码提交应该符合关注点分离原则，即将相关的修改放在一起提交，避免将不相关的修改混在一起提交。
- 提交前测试： 在提交代码前，应该进行必要的测试，以确保代码的质量和可靠性。
- 充分说明修改内容： 在提交代码时，应该充分说明本次提交的内容和修改的原因。
- 版本控制工具的使用： 应该掌握和熟练使用版本控制工具，例如Git等，以便更好地管理代码的版本和提交记录。
提交message规范
<type>(<scope>): <description> [#<issue-number>]
<body>
<footer>
其中，、、 和 # 是必填项， 可以省略， 不宜过长，最好不超过50个字符， 和 # 建议使用关键字和Issue编号的形式进行填写。
具体说明如下：
- ：提交的类型，可以是以下之一：
- feat：新功能
- fix：修复问题
- docs：文档修改
- style：代码格式修改，不影响代码运行
- refactor：重构代码
- test：测试代码修改
- chore：构建过程或辅助工具的修改
- ：影响范围，一般是指修改的文件、功能模块等，可选项。
- ：提交的描述信息，应该简短明了、清晰明了，最好不超过50个字符。
- #：可选项，可以填写对应的Issue编号。
- ：正文部分，应该对提交的修改进行详细说明，包括修改的原因、解决的问题、影响的范围等信息，最好能够清晰明了地表达提交的目的。
总之，代码提交message规范的目的是为了让代码提交记录更加清晰明了，方便团队成员查看和理解提交的内容和目的，从而提高团队协作的效率和质量。
模板
<类型>(<范围>): <主题>
<描述>
Co-authored-by: 姓名 <邮箱>
上面的message模板包含了以下几个部分：
- 类型（type）：表示提交的类型，可以使用约定俗成的关键标签（如feat、fix、docs等）或自定义标签。标签应该以小写字母开头，并用冒号（:）和空格隔开。
- 范围（scope）：表示提交的范围，可以是文件、模块、功能等。范围应该以小写字母包含在圆括号中，并用冒号和空格隔开。
- 主题（subject）：表示提交的主题，应该简洁明了，不超过50个字符。主题应该以动词开头，使用一般现在时，不要使用第一人称（如“我”、“我们”）。
- 描述（body）：表示提交的详细描述，可以包含更多的细节和上下文信息。描述应该使用简洁明了的语言，不超过72个字符宽度，可以使用多个段落。
- Co-authored-by：表示参与协作的人员信息，可以根据需要添加。
需要注意的是，使用message模板可以帮助我们规范化提交信息的格式和内容，但并不是所有的提交都需要按照模板来写。在实际开发中，我们应该根据实际情况灵活选择合适的提交信息，并确保提交信息的内容准确、清晰、简洁。
示例：
feat: 添加新功能
为某个页面添加了一个新的功能点，并优化了代码逻辑。
Co-authored-by: 张三 <zhangsan@example.com>
Co-authored-by: 李四 <lisi@example.com>
分支合并流程
简单流程：
复杂流程 ：
support 分支是一个可选的分支，用于在生产环境中维护当前正在运行的软件版本。它可以用来解决在生产环境中发现的 bug，而不会对正在进行的开发工作造成干扰。在 support 分支上修复 bug 后，这些修复将合并到 release 分支中，以便下一个软件版本的发布。
简化常用流程：
master ： 主分支，供新功能拉取
feature-dk-xxx ： 开发分支
fat: UAT环境分支，多个feature-dk-xxx 分支代码提交到该分支进行测试
release: 上线版本分支
