利用这些 Git 最佳实践成为更好的开发人员(译)

标签：例如 Git 开发人员页脚最佳 add 提交使用分支

如果您是开发人员，您可能每天都会使用名为 Git 的版本控制系统。无论是团队合作还是个人开发，使用此工具对于应用程序的开发过程都至关重要。但是，通常会遇到混乱的存储库、提交信息不明确（无法传达有用信息）以及分支滥用等问题。对于那些想要在就业市场上脱颖而出的人来说，了解如何正确使用 Git 并遵循良好的做法至关重要。

Git 分支的命名约定

当我们使用代码版本控制时，我们应该遵循的主要良好做法之一是使用清晰且具有描述性的名称来命名分支、提交、拉取请求等。确保所有团队成员的工作流程简洁明了至关重要。除了提高生产力之外，记录项目的开发过程还可以简化团队合作。通过遵循这些做法，您很快就会看到好处。

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

1. 小写

分支名称中不要使用大写字母，坚持小写；

2. 连字符分隔

如果你的分支名称由多个单词组成，请使用连字符将它们分隔开。遵循 kebab-case 约定。避免使用 PascalCase、camelCase 或 snake_case；

3. 分支命名(az, 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

分支名称约定前缀

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

feature

表示即将开发的新功能。例如feature/add-filters；

release

用于准备新版本。该前缀release/通常用于在合并来自分支 master 的新更新以创建版本之前执行诸如上次修改和修订之类的任务。例如，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

提交信息

让我们来谈谈提交信息。不幸的是，很容易找到带有“添加了很多东西”或“皮卡丘，我选择你”等提交信息的项目……是的，我曾经发现一个项目的提交信息与神奇宝贝大战有关。

提交信息在开发过程中非常重要。创建良好的历史记录将在您的旅程中为您提供很多帮助。与分支一样，提交也有社区创建的约定，您可以在下面了解：

提交信息有三个重要部分: 主题、说明和页脚

提交的主题是必需的
它定义了提交的目的
说明（正文）
用于提供提交目的的附加背景和解释。
页脚
通常用于分配提交等元数据。虽然同时使用说明和页脚被认为是一种好的做法，但这并不是必需的。

在主题行中使用祈使语气

例如：

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 的官方网站。此规范是社区中最常用的提交消息的约定。

结构

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

提交类型

我们要研究的第一个结构是提交类型。它提供了关于此提交中所做工作的清晰上下文。下面您可以看到提交类型的列表以及何时使用它们：

feat: 新功能的介绍
fix: 修复软件错误
refactor: 用于修改代码但保留其整体功能
chore: 不影响生产代码的更新，涉及工具、配置或库的调整
docs: 文档文件的添加或修改
perf: 代码改变增强性能
style: 与代码呈现相关的调整，如格式和空格
test: 纳入或修正测试
build: 影响构建系统或外部依赖项的修改
ci: 对 CI 配置文件和脚本的修改
env: 描述CI流程中的配置文件的调整或添加，例如容器配置参数

`Scope`

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

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 includes
functions for user login, registration, and password recovery.

页脚

提交消息的页脚用于提供与提交相关的其他信息。这可以包括谁审阅或批准了更改等详细信息。

例如:

Signed-off-by: John <[email protected]>
Reviewed-by: Anthony <[email protected]>

重大改变

表明提交包含重大更改，这些更改可能会导致兼容性问题或需要修改相关代码。您可以在页脚中添加BREAKING CHANGE或在类型/Scope后添加!

使用常规提交的示例

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: 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: 2
Refs: #345

参考

原文:

https://dev.to/basementdevs/be-a-better-developer-with-these-git-good-practices-2dim

标签：例如,Git,开发人员,页脚,最佳,add,提交,使用,分支
From： https://www.cnblogs.com/lenchu/p/18500245