通过这些 Git 良好实践成为更好的开发人员
如果您是一名开发人员,您可能每天都会使用名为 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:传达即将开发的新功能。例如
feature/add-filters
: -
release:用于准备新版本。该前缀
release/
通常用于在合并主分支的新更新以创建版本之前执行诸如上次修改和修订等任务。例如,release/v3.3.1-beta
; -
错误修复:它表示您正在解决代码中的错误,并且通常与某个问题相关。例如
bugfix/sign-in-flow
; -
hotfix:与 bugfix 类似,但它与修复生产环境中存在的严重 bug 有关。例如
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:新功能的介绍;
-
修复:修复软件错误;
-
重构:用于修改代码以保留其整体功能;
-
琐事:不影响生产代码的更新,涉及工具、配置或库的调整;
-
docs:文档文件的添加或修改;
-
perf:代码更改增强了性能;
-
样式:与代码呈现相关的调整,如格式和空格;
-
测试:包含或更正测试;
-
构建:影响构建系统或外部依赖项的修改;
-
ci:对 CI 配置文件和脚本的修改;
-
env:描述CI流程中配置文件的调整或添加,例如容器配置参数。
范围
范围是一种结构,可以在提交类型之后添加,以提供额外的上下文信息:
-
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 <john.doe@example.com>
Reviewed-by: Anthony <anthony@example.com>
重大改变
表明提交包含可能导致兼容性问题或需要修改依赖代码的重大更改。您可以BREAKING CHANGE
在页脚中添加,或!
在类型/范围后添加。
使用常规提交的示例
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://www.conventionalcommits.org
- https://medium.com/@abhay.pixolo/naming-conventions-for-git-branches-a-cheatsheet-8549feca2534
- https://se-education.org/guides/conventions/git.html
- https://cbea.ms/git-commit/ https://blog.geekhunter.com.br/o-que-e-commit-e-como-usar-commits-semanticos/