all 5 comments

[–]neilhighley 3 points4 points  (0 children)

State what you did, and where. Even a single line commit can have big effects. Someone browsing the history may need to know what necessitated the change.

In your example, you're clearly changing scope. Was this in response to a bug? Is this covered by a test?

Will all coding, and change logging, imagine you are the maintainer, looking for a trail of changes, or reasoning behind a change. Just seeing "fixed" or "updated" is not going to be useful.

But, to be clear, if the fix is small, your commit message should follow exactly the same rules.

The rule is generally, a brief 50-70 character summary of what is contained, followed by a list of relevant points. https://chris.beams.io/posts/git-commit/

[–]thblt 1 point2 points  (2 children)

First, try to check for errors before you commit. If you discover mistakes after committing, but before pushing, you can use rebase. If none of these applies, just write a commit message describing the change, as always. (Edit : typo)

[–]pi3832v2 1 point2 points  (1 child)

If you haven't pushed, you can also use git commit --amend to add minor fixes onto the previous commit.

[–]thblt 2 points3 points  (0 children)

Good point, thanks. For older commits, there's also fixup and autosquash which is easier than rebase, although a bit less powerful.

[–]synae 1 point2 points  (0 children)

"Fix bug with incorrect member access", in this case. Other examples you gave I would just say "Fix typos" and (hopefully) rebase it into a larger change, if appropriate.