back

by jasonpeacock·4y ago·view on hn ↗
1. Implement automation to flag and block/reject bad commit messages.

2. Educate and train ppl to include commit messages when they do code reviews

or 3. give up and move on because your org doesn't care.

Because this is a culture (not code) smell and changing culture is hard and needs support from the top.

2 comments
> Implement automation to flag and block/reject bad commit messages.

They'll just use `git commit -n` to skip the pre-commit hook.

And if it's verified in CI (e.g. with Danger), someone will just create a script to automate writing commit messages that pass the good commit message test.

And those are the people you fire because they refuse to follow policy and actively work to circumvent best practices and quality gates.
No way, (1) would annoy the heck out of people. Plus what if you want to just save off your current status and log off for the day..
Configure the enforcement only for `main` and other release/production branches, let people push whatever they want to their dev/feature branches.

When those branches are attempted to be merged they'll fail due to having bad commits and require fixing.

That's what git stash is for; you can even add a message, just like a commit, to the stash. A commit should always be in a good state, runnable, without lint or other errors.
Yes. In my experience, anything that prevents people from committing to local branches is incredibly annoying. You want people to commit frequently and “save their work.” Checks, quality barriers, etc. are fine at CI time.
> Plus what if you want to just save off your current status and log off for the day

Strictly speaking, that's what git stash [1] is for. Not so ideal if you want to push your WIP changes to Github though.

[1] https://git-scm.com/docs/git-stash