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

Question

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

Navigation

#1 by (12 votes)
#2 by (2 votes)

12

The people here where I work, for a certain period, used to not call the messages they wrote by making a git commit here.

It seems that Git was simply "a place to save things so you do not miss the changes".

So, when I needed to check the% w / o% of% w /% on a given day when a particular change was made to make a rollback , guess what ... The messages were all like this: p>

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, descriptions such as "sending changes", "all" or "sending all" do not help in describing what was done - if this message is exactly what was done, but it was the reason I figured it would exist in log .

From this day on I had this problem, we agreed that at least we would describe some of the changes that were made to commit messages. I do not know if this is the way, but something improved after that.

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

How should I write my commit messages?

versionamento git

asked by anonymous 25.04.2016 / 20:05

2 answers

2

As a rule, diff registers exactly what was done, so the commit message should:

register the " because " was done (including references to bugs relevant, etc.);

But there is no general rule, every project or developer can do whatever it thinks useful, after all it is communication by and for humans. The important thing is to establish an agreement between those involved, otherwise it will not work.

22.09.2016 / 18:26

Why does my try / catch only accept "Exception e" (Generic)? What does% = mean?

score 12 · Accepted Answer

Perhaps the problem is not the messages, but what is done in each commit . One of the advantages of Git is to facilitate granulation of commits . The rule is to make a small change, or even directly related ones and commit, even if you do not push (even though you accumulate many commits > for a push to make merge difficult). 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 altered issue # 7643
Fixed bug # 13456
Improving indentation
Implemented the interface as per such documentation
Removed redundancies
Refactoring to enable extensibility
Fixing Wallace's khdas (okay, that can not :))

I have seen some people putting some type of change marker: [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 not do this, it's better to look for another profession.

Of course, if the person does not want to write, if he does not have a minimal ability to understand what he did or to express himself, there is no rule or tool that can work.

Some people like to describe the change in depth by writing several lines. Nothing against. But that encourages people to let it go. It does not work well on 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 separate and point to another location, as in the first examples of messages I put.

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

A guide example .