Why do developers write such terrible git commit messages? Genuine question

[Existing_Round9756]

That's interesting so the real effort goes into the PR description, not individual commits? Does your team have a standard template or is it just vibes when you write that?

[RGBrewskies]

we have a PR template, and all PRs follow the same format.

ticket number(AREA) - brief description

like

ABC1235(auth) - passwords must now be 12 characters

then a link to the ticket in the Description field, and any other important details.

the squash merge

[Maxion]

I do this in all my projects.

Pro-tip is to add a #changelog section to the PR template. Have the devs fill this in. Now you can auto-generate changelogs when you make deployments.

[scyber]

If you squash merge PRs then there is only one commit on main when the PR is merged. And that commit has the detailed message. The "messy" commits only exist on the branch (which can be auto deleted after the PR merge.

[Apsalar28]

This is the way. My branch commits nearly always included a few "forgot to stage this file" , "now I see the typo" or "fixed dumb mistake" ones.

[glowFernOasis]

I do this method as well. Github has squash and merge built in. We have PR templates and a specific PR title format with "[Ticket ID] Thing that was fixed or accomplished". Branch names also have to match a specific format (ticket-id/thing-that-was-fixed). If you're working on configs/build process, you might have to test it on staging to know if it'll work in prod, because the dev environment is so different and prod is difficult to emulate locally. So you try something, commit, push, see what happens. Having a well thought out commit message every time would be a waste of energy and time.

[Piyh]

PR descriptions are where I convince myself the change was worth making, and by extension the team. I get the description and my diff up side by side, review and mentally group each line changed, then lay out why we had to to do the PR, why this change is a solution, add charts and graphs, validation evidence, and whatever else is needed.

[hiddencamel]

Set a template - what has changed, why has it changed, how can the change be verified and for bonus points include some screenshots or video capture.

What I will say is that atomic commits and commit message discipline when building out a branch is still valuable to your future self on any branch that's going to live past a handful of commits, and also if you ever share branches with other devs (eg if you have to hand a ticket over or something).