GIT 好习惯助你成为更出色的开发者

本文翻译自 Be a better developer with these Git good practices，作者：Anthony Vinicius， 略有删改。

如果你是一名开发人员，你可能每天都在使用 Git 版本控制系统。无论是在团队中还是单独工作，使用此工具对于程序的开发过程都很重要。但在实际工作中却经常遇到提交不明确的消息，没有传达有用的信息，以及滥用分支等问题。了解如何正确使用 Git 并遵循良好的实践对于那些想要在工作中脱颖而出的人来说至关重要。

Git 分支的基本约定

当我们使用代码版本控制时，我们应该遵循的主要良好实践之一是为分支、提交、拉取请求等使用清晰和描述性的名称。除了提高生产力之外，记录项目的开发过程，简化了团队沟通协作。通过遵循这些做法，你很快就会看到好处。

在此基础上，开源社区创建了一个分支命名约定，您可以在项目中遵循该约定。以下项目的使用是可选的，但它们可以帮助提高您的开发效率。

1.小写：不要在分支名称中使用大写字母，坚持使用小写字母;

2.连字符分隔：如果您的分支名称由多个单词组成，请用连字符分隔。避免 PascalCase、camelCase 或 snake_case;

3. (a-z，0-9）：在分支名称中仅使用字母数字字符和连字符。避免任何非字母数字字符;

4.请不要使用连续的连字符（--）。这种做法可能令人困惑。如果您有分支类型（如功能、错误修复、热修复等），使用斜杠（/）代替;

5.避免以连字符结束分支名称。这是没有意义的，因为连字符分隔单词，没有单词在最后分开;

6.是最重要的：使用描述性的、简洁的、清晰的名称来解释在分支上做了什么;

❎ 错误的分支名称

• fixSidebar
  

• feature-new-sidebar-
  

• FeatureNewSidebar
  

• feat_add_sidebar
  

✅ 好的分支名称

• feature/new-sidebar
  

• add-new-sidebar
  

• hotfix/interval-query-param-on-get-historical-data
  

分支名称约定前缀

有时候分支的目的并不明确。它可能是一个新功能，一个 bug 修复，文档更新，或其他任何东西。为了解决这个问题，通常的做法是在分支名称上使用前缀来快速解释分支的用途。

• feature: 将要开发的新功能。例如，feature/add-filters;

• release：用于准备新版本。前缀 release/通常用于在合并来自分支 master 的新更新以创建发布之前执行诸如最后一次修订之类的任务。例如，release/v3.3.1-beta;

• bugfix：你正在解决代码中的 bug，并且通常与问题相关。例如，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

提交信息

提交消息在开发过程中非常重要。创造一个好的历史将帮助你很多次在你的开发过程中。像分支一样，提交也有社区创建的约定，你可以在下面了解到：

• 提交消息有三个重要部分：主题、描述和页脚。提交的主题是必需的，它定义了提交的目的。描述（body）用于为提交的目的提供额外的上下文和解释。最后还有页脚，通常用于元数据，如分配提交。虽然同时使用描述和页脚被认为是一种良好的做法，但这不是必需的。

• 在主题行中使用祈使语气。举例：

Add README.md ✅;

Added README.md ❌;

Adding README.md ❌;

• 将主题行的第一个字母大写。举例：

Add user authentication ✅;

add user authentication ❌;

• 不要以句号结束主题行。举例：

Update unit tests ✅;

Update unit tests. ❌;

• 将主题长度限制为 50 个字符，要简明扼要;

• 正文以 72 个字符为单位换行，并将主题与空白行隔开;

• 如果你的提交正文有多个段落，那么用空行来分隔它们;

• 如有必要，可使用要点而非段落；

Conventional Commit's

“Conventional Commits 规范是一个基于提交消息的轻量级约定。它提供了一组简单的规则来创建提交历史。“

结构

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

提交类型

提交类型提供了一个清晰的上下文，关于在这个提交中所做的事情。下面你可以看到提交类型的列表以及何时使用它们：

• feat：引入新功能;

• fix：代码错误的纠正;

• refactor：用于代码更改重构，保留其整体功能;

• chore：不影响生产代码的更新，包括工具、配置或库调整;

• docs：对文档文件的添加或修改;

• perf：代码更改增强性能;

• style：与代码表示相关的调整，如格式和空白;

• test：纳入或纠正试验相关代码;

• build：影响构建系统或外部依赖项的修改;

• ci：更改 CI 配置文件和脚本;

• env：描述对配置项进程中的配置文件的调整或添加，例如容器配置参数。

范围

作用域是一种可以添加在提交类型之后的结构，以提供额外的上下文信息：

• fix(ui): resolve issue with button alignment
  

• feat(auth): implement user authentication
  

内容

提交消息的主体提供了有关提交所引入的更改的详细说明。它通常添加在主题行之后的空白行之后。

示例：

Add new functionality to handle user authentication.
This commit introduces a new module to manage user authentication. It includesfunctions for user login, registration, and password recovery.

Footer

提交消息的页脚用于提供与提交相关的附加信息。这可以包括详细信息，例如谁审查或批准了更改。

示例：

Signed-off-by: John <john.doe@example.com>Reviewed-by: Anthony <anthony@example.com>

Breaking Change

确认提交包含可能导致兼容性问题或需要修改相关代码的重大更改。您可以在页脚中添加BREAKING CHANGE或在类型/范围后包含!。

使用常规提交的提交示例

chore: add commitlint and huskychore(eslint): enforce the use of double quotes in JSXrefactor: type refactoringfeat: add axios and data handlingfeat(page/home): create next routingchore!: drop support for Node 18

带主题、正文和页脚：

feat: add function to convert colors in hexadecimal to 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: 2Refs: #345

最后

文本分享了日常开发中的 git 相关操作，涉及分支创建以及代码提交格式规范和示例，希望对你有帮助。

看完本文如果觉得有用，记得点个赞支持，收藏起来说不定哪天就用上啦～

专注前端开发，分享前端相关技术干货，公众号：南城大前端（ID: nanchengfe）