关于前端: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 includes
functions 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 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

最初

文本分享了日常开发中的 git 相干操作，波及分支创立以及代码提交格局标准和示例，心愿对你有帮忙。

看完本文如果感觉有用，记得点个赞反对，珍藏起来说不定哪天就用上啦～

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