What's that, you say? You've become tired of regular old boring paper checklists? Well, my friend, today is your lucky day! You, yes, you, can become the proud owner of a brand-spanking-new automatic interactive pre-commit hook checklist! You're gonna love this! Your life will be so much easier! Just wait until your friends see you.
What's a pre-commit hook?
Did you know that nearly 1 out of 5 coders are too embarrassed to ask this question? Don't worry, it's perfectly normal. In the next 60 seconds we'll tell you all you need to know to pre-commit with confidence.
A Git hook is a feature of Git that triggers custom scripts at useful moments. They can be used for all kinds of reasons to help you automate your work, and best of all, you already have them! In every repository that you initialize with git init, you'll have a set of example scripts living in .git/hooks. They all end with .sample and activating them is as easy as renaming the file to remove the .sample part.
Git hooks are not copied when a repository is cloned, so you can make them as personal as you like.
The useful moment in particular that we'll talk about today is the pre-commit. This hook is run after you do git commit, and before you write a commit message. Exiting this hook with a non-zero status will abort the commit, which makes it extremely useful for last-minute quality checks. Or, a bit of fun. Why not both!
How do I get a pre-commit checklist?
I only want the best for my family and my commits, and that's why I choose an interactive pre-commit checklist. Not only is it fun to use, it helps to keep my projects safe from unexpected off-spec mistakes!
It's so easy! I just write a bash script that can read user input, and plop it into .git/hooks as a file named pre-commit. Then I do chmod +x .git/hooks/pre-commit to make it executable, and I'm done!
Oh look, here comes an example bash script now!
#!/bin/sh
echo "Would you like to play a game?"
# Read user input, assign stdin to keyboard
exec < /dev/tty
while read -p "Have you double checked that only relevant files were added? (Y/n) " yn; do
case $yn in
[Yy] ) break;;
[Nn] ) echo "Please ensure the right files were added!"; exit 1;;
* ) echo "Please answer y (yes) or n (no):" && continue;
esac
done
while read -p "Has the documentation been updated? (Y/n) " yn; do
case $yn in
[Yy] ) break;;
[Nn] ) echo "Please add or update the docs!"; exit 1;;
* ) echo "Please answer y (yes) or n (no):" && continue;
esac
done
while read -p "Do you know which issue or PR numbers to reference? (Y/n) " yn; do
case $yn in
[Yy] ) break;;
[Nn] ) echo "Better go check those tracking numbers!"; exit 1;;
* ) echo "Please answer y (yes) or n (no):" && continue;
esac
done
exec <&-
Take my money!
Don't delay! Take advantage right now of this generous one-time offer! An interactive pre-commit hook checklist can be yours, today, for the low, low price of... free? Wait, who wrote this script?
Top comments (31)
This is soooo useful!
Thanks for sharing!
Things like this are so much more valuable as a short post with some source code you can copy and paste and change if you like compared with creating a library for download which is basically a black box and users never really learn.
Thanks guys! Glad it might be useful :)
Exactly! I can already see how I'm going to tweak this for my team. The examples are readable and straightforward.
Awesome, thanks for sharing. Question though: what if I do want to force commit something, even I'm consciously aware that I can't check every item in the checklist? For instance, sometimes there's something breaking in production and we have to roll out an hotfix right away. This means that sometimes there's no ticket associated and we're damn sure that what we're releasing will fix the problem and not break anything else. This pre commit hook wouldn't let me commit in scenario, would it?
In this specific scenario, yes, you'd probably just have to answer "Y" anyway. You'd really want to think of a checklist like this as a guideline rather than a rule anyway.
(+2 points if you name the reference)
The good thing is that even you fake the 'Y', it's still one more opportunity to think about what you're doing in the heat of battle; instead of just pressing send.
I need one of these on my emails :D
Yup! My thinking too.
"The code is more what you'd call guidelines than actual rules"
It's nicely relevant to programming as well... I might make a wallpaper with that quote !
I'm a big fan of Git and love writing about it. Hooks are one of those hidden gems that people rarely use. Thanks for enlightening us all!
Git is like an assembly line and as you write code and prepare to commit, there's a lot you can do along the process. This is DevOps 101. Asking questions precommit is a great way to keep yourself honest, but it's probably hard to enforce as a team. I would add using a solid PR template that asks these questions.
One thing this template may throttle is small commits. Forgive my strong opinions about Git, but I believe in small, agile, and transactional commits. This script might hinder that.
However, for someone starting out, it's a solid example to make sure you have your bases covered.
I would love to read more about using this method along the software development pipeline and employing checks and balances along the way to ensure solid code.
Oh my god I need this!
I really do looove good status/error messages.
Call now!!
What would your checklist be, Ben?
The way my brain works, I feel nervous trying to define a checklist. Even though I know I have one. I have commitment issues. I'm going to give this a lot of thought from this post.
From reading your other stuff, I know I approach things in a much more abstract/chaotic way. I need all the help systematizing that I can get.
Good news: bash scripts, unlike comments on the Internet, are not publicly shared! :D You can have fun writing and rewriting all you like!
Case in point: this post does not contain my actual checklist. ^^;
I don't know if you know but you can set the scripts in any language to any hooks, not neccesarily bash, just set the correct shebang in the script and no more.
Well, I'd still go with automated tests, as a colleague suggested. I believe it is very dangerous to prevent commits. As long as it is a personal branch, one should go for it and do whatever they want.
Checklists? I'd surely add them to merge/pull requests.
As a midway point, I would run my checks while detaching from the terminal and returning a 0 exit code. That way, I would still have my checks while creating my commits and keeping changes safe in their place.
Something like:
Maybe some voice messages to give alerts etc, e.g.,
saywhen using OS X.Before I forget and you think I came here to say it is a bad post: I totally loved it! :) It is very important to educate people on hooks
I love it ♥️ ♥️ ♥️ You are a 🦄
Haha, I could really use something like this, though I expect that it won't work well with the "commit often commit early" philosophy... and it could trip up GUI clients for those who use such abominations (ok, I also use them once in a while).
Instead of querying, I use automated tests.
Whatever works for whoever.
You definitely made me smile!
:D
This combined with automated testing systems would be amazing.
Nice! See also pre-commit.com/. I wonder if such manual y/n questions can be integrated into that?
Oh my gosh!! This is amazing! I can definitely see myself using this
I love automation over following conventions and/or checklists.
Great post!
Thanks Rafal! Automation all the way!
The problem with these three questions is that the developer learns to snap - without reading. Questions must include some relevant information, otherwise they are useless.
Shut up and take my money! I mean.. Great post! I think I'll use that!
:D Thanks Carles!