Is there a specific rule for commit messages in versioning systems like Git?

Question

The people here where I work, for a certain period of time, used to not care about the messages that they wrote when making a git commit around here.

It seems that Git was simply "a place to save things so as not to lose the changes".

Hence, when I needed on a given day to check on log of git when a certain change was made to make a rollback, Guess ... The messages were all like this:

commit f337a26f387b1424e977520399c14c933d63bb90
Author: Fulano
Date:   Wed Apr 20 16:10:43 2016 -0300

    All

commit 01ef74e75a6a91e20d325e2789671f51cd26463e
Author: Fulano
Date:   Wed Apr 20 14:41:46 2016 -0300

    All

commit d13ec87f63d0149b005a24a8584819100fd7085e
Author: Fulano
Date:   Wed Apr 20 14:13:41 2016 -0300
    últimas alterações


commit 4545645sad364sdfsd4234343333333asd
Author: Fulano
Date:   Wed Apr 20 14:13:41 2016 -0300
    ddddd

commit 3158b4ce189a644020ac97b51333375f6e4c2742
Author: Wallace de Souza Vizerra <[email protected]>
Date:   Fri Apr 15 15:24:45 2016 -0300

      :)

That is, the descriptions like "sending changes", "all" or "sending everything" do not help at all to describe what was done - if that message serves exactly to describe what was done, but it was the reason I imagined that it would exist in the git-commit.

From that day that I had this problem, we agreed that at the very least we would describe some of the changes that were made in the commit. I don’t know if this is the way, but it improved something after that.

So, to get more organization and standardization of my versions here, I would like to know if there is any pattern to be followed (I mean, suggested) so that it can be adopted in these messages.

How should I write my messages commit?

Answer 1

Maybe the problem is not the messages, but what is done in each commit. One of the advantages of Git is to facilitate the granulation of commits. The rule is to make a small change, or even other related directly and make a commit, even if you don’t do the push (yet accumulate many commits for a push can hinder the merge). Doing this makes it very easy to write a message.

In general people do not know what to write because it is a list of things. If the change is simple it is easy to write something useful:

• Mask of CNPJ changed Issue #7643
• Fixed bug #13456
• Improving indentation
• Implemented the x interface as documentation and
• Removed redundancies
• Refactoring to allow extensibility
• Fixing Wallace’s khdas (okay, this one can’t :) )

I have seen some people putting some marker of the type of change: [Feature], [Refactoring], [style], [bug], [performance], [testing], etc.

It has to be succinct and descriptive. So informs well and no one is lazy. If people can’t do that, better look for another profession.

Of course, if a person doesn’t want to write, if they don’t have the slightest ability to understand what they’ve done or to express themselves, there’s no rule or tool that’s handy.

Some people like to describe the change in depth by writing several lines. Nothing against it, but it encourages people to let go, it doesn’t work well in all teams.

In some cases a larger description may be useful, especially to explain the reason for the change. If it is too long it is better to document separately and point to another place, as in the first examples of messages I put.

A user needs to start doing and go instructing others. Over time if there is no coherence, there are problems in the team.

A sample guide.

Answer 2

As a rule, diff records exactly what/how it was done, so the commit message should:

• register the "because" was made (including references to bugs relevant, etc..);
• and/or say so abridged the general idea of what was (or wanted to be) done;

But there is no general rule, each project or developer can do in the way they find useful, after all it is communication by and for humans. The important thing is to make an agreement between those involved, otherwise it won’t work.