Should commit messages be written in present or pa

2019-01-30 07:26发布

So which is it that you think is better and more intuitive?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

Please provide your rationales. Note I am asking from your general perspective, meaning you should not try to associate this with your preferred svn/cvs tools or programming languages, but rather think of it as something that should/can be applied to any tools and programming languages.

12条回答
甜甜的少女心
2楼-- · 2019-01-30 07:56

I don't think it really matters. The purpose is to:

1) Convey what is or was being done, so bugs can be found easier, problems can be reverted easier, and generally be able to maintain the project easier.

2) Convey what tickets were fixed if any, so auditors (if they're used in you company can see what changes correspond to which tickets).

Lastly, if it's' already been fixed, "Fixing" doesn't make sense, and if you're still working on it, "Fixed" isn't correct.

查看更多
Viruses.
3楼-- · 2019-01-30 07:56

If it is a small commit I use present continuous:

Fixing bug 304

or

Adding comments

If it is a big commit, I do more of a change log:

  • Fixes Bug 453, 657 and 324
  • Adding Expression syntax
  • Refactored the Operator class.
查看更多
别忘想泡老子
4楼-- · 2019-01-30 07:58

I personally go with past tense ("fixed") since by the time I get to committing the bug is fixed (or I wouldn't be committing).

查看更多
劳资没心,怎么记你
5楼-- · 2019-01-30 08:02

A commit message describes why you wrote the code that is being committed.

"Fixed issue 3124", or "Fixes issue 3124" seems right because it says this code fixed|fixes issue 3124.

However, the grammar may also depend on why marks the bug as fixed. If you can mark the bug as fixed after committing, then "Fixed" is just fine, but if the bug is going to be marked as fixed by someone else after they verify your code, then "Fixes" may be more appropriate.

查看更多
贪生不怕死
6楼-- · 2019-01-30 08:04

I think the most important answer to such a question is: Everybody should use what works for a specific project and keep it at least a tiny bit consistent.

While I see the advantages of using the present tense (and in fact stumbled upon this post because I’ve seen some present tense messages in open source projects), I probably never won’t use the present tense for my projects. It’s the recommended way for Linux and Git, and probably other bigger open source projects, but I honestly don’t care as long as I’m not part of these projects.

I’m an indie dev and I use the first line of a commit message for release notes while the description in the following lines gives me an idea about implementation details. It’s a user centric workflow compared to the present tense, developer based approach. I can save some time this way. It would be extremely unnatural to give my users instructions in the release notes. It’s my job to fix bugs and to add features. I have to save time, because I’m an indie. I don’t have a “release notes writer” in my team.

Use the rules of a project if they’re already established, but stay pragmatic, and do whatever will make your work easier or faster.

查看更多
干净又极端
7楼-- · 2019-01-30 08:06

"Fix bug X" is 2 characters shorter than "Fixed bug X".
And 3 shorter than "Fixing bug X".

From the point of view of writing-short-commit-messages, the present tense sometimes / usually saves a few characters?
Which I actually think matters a little little bit e.g. with Git's recommendation of less-than-50-chars-on-the-first-commit-message-line.
Also, less text --> done reading quicker?

查看更多
登录 后发表回答