Git 分支命令管理_分支命名规范

作者：煮酒与君饮 | 2024-07-24 07:30:45

踩

分支命名规范

1 分支命名规范

Git分支命名规范可以根据具体的项目和团队的需要而有所不同，但是以下是一些常见的规范：

主分支（master/main）：这个分支通常是主要的稳定分支，它包含了当前生产环境的代码。在一些项目中，这个分支也被称为“main”。
开发分支（develop）：这个分支是开发人员用来合并所有的特性分支和bug修复分支的分支。它应该始终是最新的开发状态，并且也应该比主分支或稳定分支更频繁地进行更改。
特性分支（feature）：这些分支是用来开发新特性或功能的，通常命名为“feature/”，其中是特性名称的简短描述。
修复分支（fix）：这些分支用于修复已知的bug，通常命名为“fix/”，其中是bug的简短描述。
发布分支（release）：这些分支用于准备代码发布，例如进行代码打包，版本更新等。通常命名为“release/”，其中是该版本的版本号。
热修复分支（hotfix）：这些分支用于修复生产环境中出现的紧急bug。它们通常是从主分支或发布分支中创建的，然后在修复后合并回主分支和发布分支。通常命名为“hotfix/”，其中是bug的简短描述。

除了上述命名规范，还需要注意以下几点：

尽量使用简洁明了的命名方式，避免过长或过于复杂的名称。
统一命名方式，确保所有开发人员都能理解和遵守命名规范。
避免使用特殊字符和空格，以免在使用Git命令时出现问题。

总之，良好的分支命名规范可以让代码仓库更加规范、易于管理和维护，提高团队协作效率和代码质量。

在这里插入图片描述

2 代码提交规范

下面是归纳汇总的代码提交规范：

提交信息格式： 包括提交信息的标题和正文，其中标题应该简明扼要、能够概括本次提交的内容，正文则应该详细说明本次提交的修改和原因。
提交频率： 尽量避免频繁提交代码，应该在一定的时间间隔或者完成一定的工作量后再进行提交，以减少不必要的代码冲突和版本控制问题。
提交范围： 只提交与本次任务或者功能相关的代码，避免将不相关的代码混在一起提交。
提交顺序： 先提交修改的文件、再提交新建的文件，同时在提交前进行代码格式化、排版等操作，以保持代码的一致性和整洁性。
分支选择： 在提交代码前，应该选择正确的分支进行代码提交，避免将代码提交到错误的分支或者提交到不合适的分支上。
代码质量： 提交的代码应该符合一定的质量要求，包括编码规范、代码风格、注释规范等，以提高代码的可读性和可维护性。
版本号控制： 在代码提交时，应该遵守版本号的规范，包括MAJOR、MINOR、PATCH等版本号的更新规则。
提交记录管理： 为了方便团队成员查看和管理提交记录，应该对提交记录进行分类和整理，例如通过使用标签或者注释来标记不同类型的提交记录，或者通过使用Git log命令来查看和管理提交记录。
关注点分离原则： 代码提交应该符合关注点分离原则，即将相关的修改放在一起提交，避免将不相关的修改混在一起提交。
提交前测试： 在提交代码前，应该进行必要的测试，以确保代码的质量和可靠性。
充分说明修改内容： 在提交代码时，应该充分说明本次提交的内容和修改的原因。
版本控制工具的使用： 应该掌握和熟练使用版本控制工具，例如Git等，以便更好地管理代码的版本和提交记录。

提交message规范

<type>(<scope>): <description> [#<issue-number>]

<body>

<footer>
1
2
3
4
5

其中，、、和 # 是必填项，可以省略，不宜过长，最好不超过50个字符，和 # 建议使用关键字和Issue编号的形式进行填写。
具体说明如下：

提交的类型，可以是以下之一
feat：新功能
fix：修复问题
docs：文档修改
style：代码格式修改，不影响代码运行
refactor：重构代码
test：测试代码修改
chore：构建过程或辅助工具的修改
影响范围，一般是指修改的文件、功能模块等，可选项。
提交的描述信息，应该简短明了、清晰明了，最好不超过50个字符。
#：可选项，可以填写对应的Issue编号。
正文部分，应该对提交的修改进行详细说明，包括修改的原因、解决的问题、影响的范围等信息，最好能够清晰明了地表达提交的目的。
可选项，可以包含一些提交元数据，如作者、协作者、变更记录等信息。

总之，代码提交message规范的目的是为了让代码提交记录更加清晰明了，方便团队成员查看和理解提交的内容和目的，从而提高团队协作的效率和质量。

模板

<类型>(<范围>): <主题>

<描述>

Co-authored-by: 姓名 <邮箱>
1
2
3
4
5

上面的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>
1
2
3
4
5
6

3 分支合并流程

简单流程：
在这里插入图片描述

复杂流程：
在这里插入图片描述

support 分支是一个可选的分支，用于在生产环境中维护当前正在运行的软件版本。它可以用来解决在生产环境中发现的 bug，而不会对正在进行的开发工作造成干扰。在 support 分支上修复 bug 后，这些修复将合并到 release 分支中，以便下一个软件版本的发布。

简化常用流程：
在这里插入图片描述
master ：主分支，供新功能拉取
feature-dk-xxx ：开发分支
fat: UAT环境分支，多个feature-dk-xxx 分支代码提交到该分支进行测试
release: 上线版本分支

原文链接：https://blog.csdn.net/ityqing/article/details/134413254

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/煮酒与君饮/article/detail/873506