Commit naming guide?

Question

git

There are a bunch of guidelines/styles for maintaining a development repository using git, but most of the rules are branching.
Maybe there are articles / own rules for naming commits?
I just committed this piece of code

if (null !== $currentCharset = $this->getCharset()) {
-            $content = iconv($this->getCharset(), $charset, $this->content);
+            $content = iconv($currentCharset, $charset, $this->content);
         } else {
             $content = $this->content;
         }

Calling it "fix CurlResult::fetch charset logic"
But in fact, I only corrected a typo and the previous code worked fine, just pulled the method once again.

Answer 1

What is the point of writing the method / string / variables that you replaced in the commit name? This can be seen from the commit. But the logic that your commit changed needs to be described. For example, "fix charset encoding on HTTP requests".

Answer 2

The commit encodes information about the task number and its name. Your example fits well on commit ---amend, that's what branches are for, so that typos are not fixed by a separate commit. In general, I try to adhere to the rule whenever possible - one task, one branch, one commit and amend allows you not to spread the logic over the commits.

Answer 3

It seems to me that a lot depends on who exactly will use the comments (program developers, users, etc.) and how exactly, what will determine the level of abstractness of the comment and its content.
The best, in my opinion, is to write a comment as a brief description of the changes from the standpoint of one’s own vision of the meaning of the changes being made, guided by the changes actually made (i.e. not to “fly away” too high in abstraction when describing the changes) and proceed from the fact that comments are for developers. If a spelling error is corrected, then the comment should indicate that “a spelling error has been fixed”, if several sections of the code have been changed for the sake of general logic, then it should be described what kind of logic is meant (i.e., give exactly a description of the general, abstract logic, and not list changed methods, classes, etc.).
In the case of your example, I think you should have written something like “Removed an extra call to the getCharset function in CurlResult::fetch” (to make your intentions clear; you removed the call because it is superfluous (which you even wrote about later in your post - “I just pulled the method once again”), and not for the sake of correcting some mistake).
As for the use in the comment of the names of entities from the program code (names of methods, classes, namespaces, etc.) that have been changed, then, in my opinion, one should try to find a balance between the desire to specify the scope of changes and the size of the comment (i.e. i.e. I am for the presence in the comment of an indication of the area of ​​\u200b\u200bchanges, just the specification will vary from the name of specific entities from the program code to generalized names). So, for example, instead of the comment "added support for recursive deletion of files" I would prefer the comment "added support for recursive deletion of files in the removeDirectory function"), and instead of the comment "added support for events in the classes Plugin1, Plugin2, Plugin3" I would prefer "added support for events in plugins.
You can also try to configure the viewer so that at the beginning of the comment it displays the common path for all modified files (it will help if the program respects the correspondence between the file name and the program entity contained in it).

Answer 4

We usually do this.
As a rule, one task (feature or bug) is one commit with the comment “issue number: task name”. The task is written in a separate branch with a bunch of commits like fix-fix-fix. Before a pull request, the commits are merged into one using git rebase. This approach makes it easy to roll back fixes.
If the task is very large, you can break it into subtasks or a checklist, then each subtask can correspond to one commit. If you need to make a small change, write, for example, "0000: minor changes" or "0000: typo fixed".

Answer 5

tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Answer 6

mercurial.selenic.com/wiki/ChangeSetComments

Answer 7

Sorry, posted a link here that doesn't make sense.

Answer 8

There is an option to mark such places with TODOs (when noticed), with a note of what needs to be fixed and that this is refactoring, and after some periods of time arrange code refactoring in these places with a branch into a separate branch.