常规提交如何提高我的 git 技能

工作原理

写这篇文章的时候，我正处于实习的最后一个月。我慢慢意识到过去几个月我学到了多少东西。但在所有我学到的东西中，对 git 有了更好的理解和使用，这是对我影响最大的一点。在这次实习之前，每当我推送修改时，我都会这样做：

git add .
git commit -a -m “added a few features” 
git push 

就这样。我通常会在一天结束的时候，或者我不想丢失进度的时候这样做。然而，在这家公司，我养成了按照一种标准化结构提交的习惯，这种结构叫做“常规提交”。

工作原理

您不需要“仅仅”编写消息，而是遵循如下模板：

<type>[optional scope]: <description>

[optional body]

[optional footer]

每个提交都有一个属于预定义类别的类型，在该公司，具体类别是：

• feat：最终用户可见的功能。
• fix：最终用户可见的错误修复。
• chore：不会影响最终用户的变更（例如 CI 管道的机会）
• docs：README 或文档的变更
• refactor：生产代码的改变侧重于可读性、风格和/或性能。

范围指定了你修改了什么，最好用一个词来表达。
描述用一行文字来说明修改的内容。如果提交信息中需要包含更多信息，可以使用正文。最后，还有一个页脚，你可以在这里标记相关的问题或拉取请求。

“常规提交”的一个例子：

git commit -m "feat(ratings): added the ability to add star ratings to posts.

This has been a feature requested by different users. 
Changes in the database structure where necessary to make this happen. 

closes #105"

使用这种提交结构会影响我每天使用版本控制的方式以及提交消息的“质量”。

1. 更具描述性的提交

我认为最明显的变化是我的提交比以前更具描述性。通过提供类型和范围，通常可以在查看提交的文件之前就更清楚地找到更改的位置。这也使得描述能够集中于更改的内容，因为其他细节已经知道。尽管正文和页脚是可选的，但它们对未来非常有用。例如，如果正文描述了某个 bug 的修复方式以及它所指向的问题，那么当发现该修复无意中导致了其他功能的行为发生变化时，就会非常有用。

2. 工作流程的改变

使用传统提交时，我无法将所有更改都集中到一次提交中。我必须花时间思考自己最初做了什么。然后基于此，我开始提交工作。例如，当我添加重要功能或更改持续集成 (CI) 流程时，我仍然会立即编辑文档。我不会一次性提交所有内容，而是暂存某些文件并编写相应的提交消息。一开始，这似乎需要大量工作，但当出现问题或与预期不符时，从版本控制的角度来看，查找更改发生的时间会容易得多。

3. 使用更多 git 功能

除了“正确”的暂存功能外，我还使用了许多其他 git 功能。公平地说，这也与 git 工作流程的其他方面有关（将生产代码和开发代码分离到不同的分支中）。重写提交消息或删除上次本地提交是我以前从未做过的事情。

使用这种提交结构还有很多好处。其中之一就是可以使用工具生成清晰的变更日志，并且使用某些关键字可以触发 Github 和 Bitbucket 等代码库托管解决方案中的一些酷炫功能。了解 Git 的最佳方式就是使用它。我承认，在尝试新事物时，我确实会犯一些错误。我强烈推荐Git Flight Rules代码库，以防万一出现问题或你不确定该怎么做。

希望您愿意亲自尝试常规提交。〜
编码愉快：）