If you're using git to manage your codebase as a team, you've probably heard of git hooks*.
They are a workflow that triggers a set of scripts and tasks to ensure specific aspects of your development practices are taken care of out of the box.
Back in Confluence, we had some client side pre-commit hooks that took care of running checkstyle and linting on the staged files so we always commit our code with style; and we also had some server side pre-receive hooks that made sure no one ever merges to the main branch on purpose or by accident.
Yes, absolutely, I agree
Sometimes you just want to commit your changes and move on, so my favourite hook is pre-push instead.
Anytime I finish a body of work and I am ready to push it upstream, the hook runs some of the sanity checks for me locally (compile, lint, unit tests ...) before anything hits the server and triggers the whole pipeline 💵 🤑
... and if I don't have a minute to sit around and wait for the results I can always just push my code with --no-verify
... #yolo
Maybe, maybe not
I personally don't like my silly typos and silly compile errors to trigger builds, waste resources, and give me the false impression that I can be off the hook for a moment so I can switch context and do something else.
That's possibly a side effect of working on large enterprise products where context switching is mentally expensive.
Yes, there's prepare-commit-msg hook which lets you manipulate the commit message and is traditionally used to add a prefix/suffix like an issue tracker number ... ahem ... ahem ... yes I meant to say a Jira issue number
So one would define a branch naming pattern for their team, something like
bugfix/ISSUE-1234-description
orfeature/ISSUE-1265-description
orpatch/ISSUE-7632-description
For each commit made on a given branch , the prepare-commit-msg hook would parse the issue number from the branch name and add it as prefix to the commit message typed either through CLI git commit -m "I did this because that"
or through and IDE/SourceTree/SomeDesktopGitClient