likes
comments
collection
share

提升开发者能力：遵循Git使用良好习惯

作者站长头像
站长
· 阅读数 29

如果您是一名开发人员，那么您可能每天都会使用称为Git的版本控制系统。无论是团队合作还是个人项目，这个工具在应用程序的开发过程中都是至关重要的。然而，经常会遇到混乱的代码库、不清楚的提交信息，以及分支的错误使用等问题。了解如何正确使用Git并遵循良好的实践对于那些想在职场上脱颖而出的人来说是必不可少的。

翻译至：☞ლ(′◉❥◉｀ლ)

一、Git分支命名规范

在进行代码版本控制时，我们应遵循的主要良好实践之一是为分支、提交、拉取请求等使用清晰且具有描述性的名称。确保所有团队成员都能够简洁地进行工作流程是至关重要的。除了提高生产力外，历史上记录项目的开发过程还可以简化团队合作。通过遵循这些实践，您将很快看到好处。

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

  1. 小写：分支名称不要使用大写字母，保持小写；

  2. 用连字符分隔：如果您的分支名称由多个单词组成，请使用连字符将它们分隔开，遵循kebab-case约定。避免使用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

二、分支命名约定前缀

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

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

  • release: 用于准备一个新的发布。通常使用前缀 release/ 来执行诸如最后触及和修订等任务，然后将从主分支合并新更新以创建一个发布。例如，release/v3.3.1-beta；

  • bugfix: 表示你正在解决代码中的 bug，通常与某个问题相关。例如，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

三、提交消息

让我们来谈谈提交消息。不幸的是，很容易在项目中找到像"added a lot of things"或者"Pikachu, I choose you"这样的提交消息……是的，我曾经发现一个项目的提交消息与宠物小精灵战斗有关。

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

一个提交消息包含三个重要部分：主题（Subject）、描述（Description）和页脚（Footer）。提交的主题是必需的，用于定义提交的目的。描述（正文）用于提供关于提交目的的额外上下文和解释。最后，页脚通常用于指定提交的元数据。虽然同时使用描述和页脚被认为是一个好习惯，但并非必需。

  • 在主题行中使用祈使句。例如：

Add README.md ✅;

Added README.md ❌;

Adding README.md ❌;

  • 主题行首字母大写。例如：

Add user authentication ✅;

add user authentication ❌;

  • 不要在主题行末尾使用句号。例如：

Update unit tests ✅;

Update unit tests. ❌;

  • 将主题行限制在50个字符内，即清晰而简明；

  • 在正文中每行限制为72个字符，并使用空行将主题与正文分隔开；

  • 如果你的提交正文有多个段落，使用空行将它们分隔开；

  • 如果需要，可以使用项目符号来代替仅使用段落。

四、常规提交

“Conventional Commits”（常规提交）规范是在提交消息上的一种轻量级约定。它提供了一组简单的规则，用于创建明确的提交历史。

以下引用来自“Conventional Commits”官方网站。这个规范是社区中使用最广泛的提交消息约定。

结构：

<类型>[可选范围]： <描述>

[可选正文]

[可选页脚]

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

其中：

  • <类型>：表示提交的类型，例如 feat 表示新功能，fix 表示修复 bug，docs 表示文档变更等。
  • [可选范围]：描述提交的范围，为受影响组件提供额外的上下文信息（例如用户、认证、主页）。
  • <描述>：简要描述提交引入的变更。
  • [可选正文]：提供更详细的变更描述，以 72 个字符为界限换行，并与主题行用空行分隔。
  • [可选页脚]：包含任何附加信息，如问题跟踪器 ID、重大变更或相关问题的引用。

遵循“Conventional Commits”的结构有助于保持一致且信息丰富的提交历史，使我们更容易理解代码库的演变并自动化发布流程。

Commit类型

我们首先要学习的是提交类型。它为提交提供了清晰的上下文，说明了此提交的内容。以下是提交类型的列表以及何时使用它们：

  • feat：引入新功能；

  • fix：修复软件错误；

  • refactor：进行代码修改，保持其整体功能不变；

  • chore：更新不影响生产代码的内容，涉及工具、配置或库的调整；

  • docs：添加或修改文档文件；

  • perf：改善性能的代码更改；

  • style：与代码格式和空白等相关的调整；

  • test：包括或更正测试；

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

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

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

Scope

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

  • fix(ui)：解决按钮对齐问题；

  • feat(auth)：实现用户认证；

Body

提交消息的正文提供了关于提交引入的变更的详细说明。通常在主题行之后的空行之后添加。

Example:

feat(auth): 添加新功能以处理用户身份验证。 此提交引入了一个新模块，用于管理用户身份验证。它包括用户登录、注册和密码恢复的功能。

Breaking Change

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已经成为最流行的版本控制工具之一。遵循Git的良好实践不仅有助于个人开发者更好地管理代码，也有助于团队协作更加高效。要成为更优秀的开发者，以下是一些关于遵循这些Git良好实践的总结：

首先，保持代码库整洁。定期清理不再使用的分支，删除不必要的代码和文件，确保代码库结构清晰简洁。这样可以提高代码可读性，减少混乱和错误。

其次，频繁提交并编写有意义的提交信息。将工作分解为小的逻辑变更，并及时提交到版本控制系统。每次提交都应该附带有描述性的提交信息，说明这次变更的目的和内容，方便他人理解和回溯变更历史。

第三，合理使用分支管理。合理规划分支结构，避免过多无意义的分支，保持主干稳定。使用feature分支来开发新功能，bugfix分支来修复问题，release分支来发布版本，hotfix分支来紧急修复线上问题，有效利用分支管理能够提高团队协作效率。

第四，定期进行代码审查。通过代码审查可以发现潜在问题、改进代码质量，保证团队代码风格一致性。代码审查也是学习和交流的机会，有助于个人和团队不断提升。

最后，养成良好的团队协作习惯。及时与团队成员沟通，遵循团队约定的工作流程，相互合作，共同进步。尊重他人的工作成果，保持开放的心态，乐于接受反馈和改进建议。

遵循Git的良好实践有助于个人成长和团队发展，提高代码质量、团队效率，成为更优秀的开发者。坚持不懈地实践这些原则，将会在软件开发领域取得更大的成就。

转载自:https://juejin.cn/post/7338258719790759970
评论
请登录