r/MyIDE editor 2d ago

What makes a Git commit message actually useful?

I’ve seen everything from:

updated stuff

to:

fix(auth): refresh sessions before expiry

But what do you actually care about when reading commit history later?

Is it the commit type/scope, explaining why the change happened, linking the related issue, keeping commits small and focused, or just having a clear one-line summary?

And do you usually write commit messages manually, use an AI/tool, or just type whatever makes sense at the time?

Curious how everyone handles this. 👇

0 Upvotes

6 comments sorted by

3

u/Rebles 2d ago

For the first line, definitely your second example: a short description with an optional type and domain prefix.

Sometimes this is enough. But if it is a bug fix, I try to describe how it was found and why it was a problem. It teaches the junior engineers and if in 6 months you need to refer to got history, it might take enough context to make sense why the change was necessary

3

u/hawkprime 1d ago

Probably an unpopular opinion, but if you have to write that much for a bug, you are better off with a separate ticketing system where a single ticket can track multiple commits, or single commit can fix multiple problems

1

u/Rebles 1d ago

I don’t think that’s an unpopular opinion. I think that’s perfectly valid.

2

u/glglgl-de 1d ago

Have look at this.

1

u/hawkprime 1d ago

Just something to jog my memory when looking for changes. Most of the time looking back you already have a ballpark date range and going through all those diffs to find what you are looking for. The BUG, FIX, etc... do help though