3 ms·

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

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.

toomanybeersies 5y ago
> 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.
- jasonpeacock 5y ago
  And those are the people you fire because they refuse to follow policy and actively work to circumvent best practices and quality gates.
hackerbrother 5y ago
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..
- jasonpeacock 5y ago
  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.
- toomanybeersies 5y ago
  > 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 https://git-scm.com/docs/git-stash
- icedchai 5y ago
  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.
- blindmute 5y ago
  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.

toomanybeersies 5y ago

> 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.

jasonpeacock 5y ago
And those are the people you fire because they refuse to follow policy and actively work to circumvent best practices and quality gates.

hackerbrother 5y ago

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..

jasonpeacock 5y ago
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.
toomanybeersies 5y ago
> 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 https://git-scm.com/docs/git-stash
icedchai 5y ago
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.
blindmute 5y ago
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.