How to write comments on commits?

knott2012-09-04 14:35:50

CVS

knott, 2012-09-04 14:35:50

Please tell me how to write comments to commits correctly so as not to create a rake in history and not get a slap from a colleague?
Are there any more or less generally accepted guidelines on this?
Answers based on personal experience are naturally welcome.

Answer the question

In order to leave comments, you need to log in

9 answer(s)

Vladimir Chernyshev, 2012-09-04
@VolCh

The Pro Git book recommends writing the commit name (short description) starting with the English verb in the imperative: "Fix", not "Fixed" or "Fixing"

wartur, 2012-09-04
@wartur

Well. I have not read the books, but if they are here it will be very useful.
> so as not to create a rake in history and not get a slap from a colleague?
Well, you need to agree at the beginning with everyone how you will do it. And then a strange bacchanalia of slaps on the back of the head all over the team will begin =)
As usual with us:
Our comment is divided into several parts.
1) a conditional word that is done. fix (fixed), unstanle (means that this version cannot be updated to the production server)
2) on a new line, a link to the bugtracker, which describes the problem ( http:// mantis/issue/id conditionally), and comment ID(s) in question.
3) Possible comments, through a dash on a new line each
- comment1
- comment2

====== Пример 1

fix
http:// ....
- решено то
- решено сё

====== Пример 2

unstable
http//..... 1233, 1235
- не исправлена на чистовую версию синхронизация

====== Пример 3

fix
http//..... 1233, 1235</code>

Astashov_Anton, 2012-09-05
@Astashov_Anton

tpope wrote about it: tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
It's about git, but it can be applied to any VCS.

madmaxcorp, 2012-09-04
@madmaxcorp

Well, we had: “Ticket number in JIRA - something has been done”

TheHorse, 2012-09-04
@TheHorse

Currently using:
<Subsystem name>:<What's done.>
Example:
Gaia: Implemented type traits for memcpy relocation.
Quality criteria in this context are obvious:
1. The comment should be such that it is possible to understand where the changes were made.
2. The comment should be such that it is possible to understand what has been done.
3. Comment should be concise.
Dates, nicknames and others do not need to be inserted because this information is already in the SUV.

Vampiro, 2012-09-04
@Vampiro

I imagine what I will type in the search bar if I have to look for this particular commit, and I insert the appropriate words. It seems to me that the main meaning of the comment is precisely in displaying the essence of the changes and the possibility of later finding out who did it and when, and rolling back, if anything. Even when I work in the system, I alone help. Well, it's nice to read how progress was made last week, for example. :)

Nikolai Turnaviotov, 2012-09-04
@foxmuldercp

These things are usually negotiated by the team. someone like. when the ticket number, when just a comment “feature such and such” / “solution to the problem such and such”

easyman, 2012-09-05
@easyman

If nothing comes to mind - whatthecommit.com/

Progrik, 2012-09-05
@Progrik

We have an article about this: trilandev.com/2012/03/git-comments.html
We try not to deviate from its principles