前言
如果您是一名开发人员，您可能每天都会使用名为 Git的版本控制系统。无论是团队工作还是个人工作，该工具的使用对于应用程序的开发过程都至关重要。 然而，通常会遇到混乱的存储库、提交的消息不明确、无法传达有用信息以及滥用分支等问题。对于那些想要在开发工作中脱颖而出的人来说，了解如何正确使用 Git 并遵循良好实践至关重要。
Git规范
当我们使用代码版本控制时，我们遵循的主要规范之一是为分支、提交、拉取请求等使用清晰且描述性的名称。确保所有团队成员的简洁工作流程至关重要。 除了提高工作效率之外，还可以记录项目的开发过程以及简化团队合作。 通过遵循这些做法，您很快就会看到好处。
基于此，您可以在项目中遵循以下分支命名约定，它们可以帮助提高您的开发技能。
Git分支的命名约定
1.小写：分支名称不要使用大写字母，坚持用小写字母；
2.连字符分隔：如果您的分支名称由多个单词组成，请用连字符分隔它们。遵循烤肉串规则。避免使用如PascalCase、camelCase 或 Snake_case；
3.（a-z、0-9）：分支名称中仅使用字母数字字符和连字符。避免使用任何非字母数字字符；
4.请不要使用连续的连字符 (--)。这种做法可能会令人困惑。例如，如果您有分支类型（例如feature, bugfix, hotfix等），请改用斜杠 (/)；
5.避免分支名称以连字符结尾。这是没有意义的，因为连字符分隔单词，并且末尾没有单词可以分隔
6.这种做法是最重要的：使用描述性的、简洁的、清晰的名称来解释在分支上做了什么；
错误的分支名称范例：
fixSidebar
feature-new-sidebar-
FeatureNewSidebar
feat_add_sidebar
正确的分支名称范例：
feature/new-sidebar
add-new-sidebar
hotfix/interval-query-param-on-get-historical-data
分支名称前缀约定
有时分支的目的并不明确。它可以是新功能、错误修复、文档更新或其他任何内容。为了解决这个问题，通常的做法是在分支名称上使用前缀来快速解释分支的用途。
feature: 它表示将要开发的新功能。例如, feature/add-filters;
release:用于准备新版本。前缀release/通常用于合并来自分支主服务器的新更新。例如release/v3.3.1-beta;
bugfix: 表示您正在解决代码中的错误，它与开发测试过程中错误有关。例如, bugfix/sign-in-flow;
hotfix：与bugfix类似，但它与修复生产环境中存在的严重错误有关。例如hotfix/cors-error;
docs：编写一些文档。例如docs/quick-start;
如果您正在使用任务管理工作流程，例如 Jira、Trello、ClickUp 或任何可以创建用户故事的类似工具，则每张卡片都有一个关联的编号。因此，通常在分行名称的前缀上使用这些卡号。例如： feature/T-531-add-sidebar docs/T-789-update-readme hotfix/T-142-security-path
提交消息
让我们来谈谈提交消息。不幸的是，在项目中很容易找到带有“added a lot of things”或“fix bugs”之类的提交消息。......我曾经发现一个项目，其中提交消息与神奇宝贝战斗有关。 提交消息在开发过程中非常重要。记录一段美好的开发历史将在你的开发生涯中给你带来很多帮助。您可以在下面了解：
.提交消息包含三个重要部分：主题、说明和页脚。 提交的主题是必需的，它定义了提交的目的。 描述（正文）用于为提交的目的提供额外的上下文和解释。 最后是页脚，通常用于元数据，例如分配提交。 虽然同时使用描述和页脚被认为是一种很好的做法，但这不是必需的。
- 在主题行中使用祈使语气。例如：
- Add README.md ✅;
- Added README.md ❌;
- Adding README.md ❌;
- 主题行的第一个字母大写。例如：
- Add user authentication ✅;
- add user authentication ❌;
- 不要以句号结束主题行。例如：
- Update unit tests ✅;
- Update unit tests. ❌;
-
主题行限制在 50 个字符以内，即清晰、简洁；
-
并将主题与空行分隔开；
-
如果您的提交正文有多个段落，请使用空行将它们分开；
一般提交
"The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history."
以下引用来自Conventional Commit 的官方网站。该规范是社区中提交消息最常用的约定。
结构
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
提交类型
我们要研究的第一个结构是提交类型。它提供了有关此提交中所做操作的清晰上下文。您可以在下面看到提交类型列表以及何时使用它们：
feat: 加入新功能
fix: 修复软件错误
refactor: 用于代码更改，保留其整体功能；
chore: 更新不影响生产代码，涉及工具、配置或库调整；
docs: 对文档文件的添加或修改；
perf: 代码更改可提高性能；
style: 与代码格式相关的调整，例如格式和空白；
test: 加入或更正测试；
build: 影响构建系统或外部依赖项的修改；
ci: CI 配置文件和脚本的更改；
env: 描述CI 流程中配置文件的调整或添加，例如容器配置参数。
范围
范围是一种结构，可以在提交类型之后添加以提供额外的上下文信息： fix(ui): 解决按钮对齐问题
feat(auth): 实施用户认证
正文
提交消息的正文提供了有关提交引入的更改的详细说明。它通常添加在主题行后面的空白行之后。
例如：
添加新功能来处理用户身份验证。
此提交引入了一个新模块来管理用户身份验证。这包括用户登录、注册、找回密码等功能。
注脚
提交消息的页脚用于提供与提交相关的附加信息。这可以包括诸如谁审查或批准了变更之类的详细信息。
例如： Signed-off-by: John john.doe@example.com Reviewed-by: Anthony anthony@example.com
破坏性的变更 指示提交包含可能导致兼容性问题或需要修改相关代码的重大更改。您可以在页脚中添加重大更改或包含！(在类型/范围之后)。
例如：
- chore: add commitlint and husky
- chore(eslint): enforce the use of double quotes in JSX
- refactor: type refactoring
- feat: add axios and data handling
- feat(page/home): create next routing
- chore!: drop support for Node 18
完整样例：
feat: 添加将十六进制颜色转换为rgba的功能
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum has been the industry's standard dummy text ever since the 1500s.
Reviewed-by: 2
Refs: #345
