git团队如何提交_如何使您的提交消息很棒并保持团队快乐

git团队如何提交

by Bruno

由Bruno

如何使您的提交消息很棒并保持团队快乐 (How to make your commit messages awesome and keep your team happy)

提交消息是团队成员之间进行交流的重要手段 (Commit messages are important means of communication between team members)

What matters most in team software development is communication. Commit messages are important means of communication between team members: its past and its future.

团队软件开发中最重要的是沟通。 提交消息是团队成员之间交流的重要手段：过去和将来。

When analysing the code or debugging, we all have questions like:

在分析代码或调试时，我们都有以下问题：

• Why is this if here?

  为什么在这里呢？

• Who forgot to update the branch?
  谁忘了更新分支？
• What impact has this change had?
  此更改产生了什么影响？
• How can this change ever fix or improve the code?
  此更改如何修复或改进代码？

To this end, git-blame allows us to discover which revision was the last to change the file. But just knowing that is not good enough. Would be helpful to actually read the commit message to understand what really happened there.

为此， git-blame允许我们发现哪个修订是最后一次更改文件。 但是仅仅知道这还不够。 实际阅读提交消息以了解实际发生的情况将很有帮助。

We need to read the message to experience the real value of a good commit message, and be motivated to write them.

我们需要阅读消息以体验好的提交消息的真正价值，并有动力编写它们。

一些最佳做法 (Some best practices)

So, if the majority of your Git commits so far have been created with something like git commit -m "9000 — Bug fixes issue" then next time try this guideline:

因此，如果到目前为止，您的大多数Git提交都是使用git commit -m "9000 — Bug fixes issue"类的东西创建的，则下次尝试以下准则：

Never use the -m <msg&gt; / --message=<msg&gt; flag to git commit.

切勿使用-m <m sg＆ gt; / --message gt; / --message = <msg＆ gt; flag t gt; flag t git commit。

It gives you a poor mindset right off the bat as you will feel that you have to fit your commit message into the terminal command, and makes the commit feel more like a one-off argument than a page in history.

它使您立即失去了良好的心态，因为您会感觉到必须将提交消息放入终端命令中，并使提交感觉更像是一次性的参数，而不是历史上的一页。

The first line should always be 50 characters or less and it should be followed by a blank line.

第一行应始终为50个字符或更少，并且后跟空白行。

Write an imperative tense: “Fix bug”. [Add |Fix | Remove| Update| Refactor] Consistent wording makes it easier to mentally process a list of commits.

写下命令式时态：“修复错误”。 [ 添加|修复| 删除| 更新| 重构 ]一致的措词使从心理上处理提交列表变得更加容易。

72-character wrapped longer description.

包含72个字符的较长说明。

Often a subject by itself is sufficient. When it’s not, add a blank line (this is important) followed by one or more paragraphs hard wrapped to 72 characters.

通常一个主题本身就足够了。 如果不是，请添加一个空白行(这很重要)，然后是一个或多个段落，这些段落硬包装为72个字符。

Those paragraphs should explain:

这些段落应说明：

Why is this change necessary?

为什么需要进行此更改？

This answer explains what to expect in the commit, allowing them to more easily identify and point out unrelated changes.

该答案解释了提交中的期望，使他们可以更轻松地识别并指出无关的更改。

How does it address the issue?

如何解决这个问题？

Describe, at a high level, what was done to affect change. If your change is obvious, you may be able to omit addressing this question.

从高层次描述影响变更的措施。 如果您的更改很明显，则可以忽略该问题。

What side effects does this change have?

此更改有哪些副作用？

This is the most important question to answer, as it can point out problems where you are making too many changes in one commit or branch. One or two bullet points for related changes may be okay, but five or six are likely indicators of a commit that is doing too many things.

这是最重要的问题，因为它可以指出在一个提交或分支中进行过多更改的问题。 一到两个要点，可以进行相关的更改，但五到六个可能是表示所做的事情过多的指示。

# 50-character subject line## 72-character wrapped longer description. This should answer:## * Why was this change necessary?# * How does it address the problem?# * Are there any side effects?## Include a link to the ticket, if any.

如何让生活更轻松 (How to make your life easier)

It’s a lot to remember, but you can set up a commit message template by using the commit.template

很多事情要记住，但是您可以使用commit.template设置提交消息模板

Configure Git to use a template file (for example, .gitmessage), then create the template file with Vim:

配置Git以使用模板文件(例如.gitmessage )，然后使用Vim创建模板文件：

git config --global commit.template ~/.gitmessagevim ~/.gitmessage

When we run git commit without the -m message flag, the editor will open our helpful template ready to go:

当我们运行不带-m message标志的git commit ，编辑器将打开我们准备使用的模板：

# [Add/Fix/Remove/Update/Refactor/Document] [summary]# Why is it necessary? (Bug fix, feature, improvements?)-# How does the change address the issue? -# What side effects does this change have?-# Include a link to the ticket, if any.

Commented lines are not included in the final message. Simply fill in the blank lines with text and bullet points under the prompts.

注释行不包含在最终消息中。 只需在提示下用文本和项目符号点填充空白行。

Issue trackers in GitHub and Bitbucket both recognise the keywords close, fix, and resolve followed immediately by the issue or pull request number.

GitHub和Bitbucket中的问题追踪器都可以识别关键字close ， fix和resolve紧随其后的是问题编号或请求编号。

I think Linus would be very happy if we didn’t use git commit -m "Fix bug" in a public repository ever again :)

我认为如果我们不再在公共存储库中再次使用git commit -m "Fix bug" ，Linus将非常高兴：)

You can simple search in git log for a issue number, for example, with git log --grep=JIRA-1234

您可以在git log中简单地搜索问题编号，例如，使用git log --grep=JIRA-1234

You can also use plugins like vim-fugitive for vim or git lens for vs code to quickly access to git commit messages.

您还可以使用插件，像vim-fugitive的VIM或git lens为VS码 ，以便快速访问git的提交信息。

总结思想 (Closing thoughts)

Creating clean Git commits says a lot about you and may be a primary way that people interact with you over projects.

创建干净的Git提交对您有很多影响，这可能是人们通过项目与您进行交互的主要方式。

With a little practice, you can make your commit habits an even better reflection of your best work — work that is evidently created with care and pride.

稍加练习，就可以使自己的养成习惯更好地反映出您的最佳工作-显然是精心和自豪地创造的。

Your future you, and your team, will thank you for your forethought and verbosity when they run git blame to see why that conditional is there.

您的未来，以及您和您的团队，将在感谢git blame时了解您为什么有条件，感谢您的前瞻性和冗长的技巧。

If you enjoyed this article please clap, recommend and share.

如果您喜欢这篇文章，请鼓掌，推荐并分享。

翻译自: https://www.freecodecamp.org/news/level-you-up-to-awesome-commit-messages-a85558cb90e8/

git团队如何提交