Hooked on GitApril 11, 2016
Hooked on Git
At some point in your career as a software developer, you’ve probably typed in a Git commit message similar to the following:
Fix style checker warnings
Fix style checker warnings AGAIN...
Fix broken test
Commits like these tend to happen when you forget to run your code linters or test suite before pushing code to the remote repository. A continuous integration server never forgets to run these and posts angry red messages to your Slack channels when the build fails.
Fortunately, Git has a hooks feature which can run checks for you automatically at certain points in your workflow such as:
- Before you commit (
- After you write a commit message (
- Before you push to a remote (
There are several more events that Git has hooks for, but I’ve found that these three are the most useful to me.
I commonly use this hook to catch whitespace related issues, namely ensuring that the files getting committed have a newline at the end of the file and contain no trailing whitespace. When you run
git commit, git will run the
pre-commit hooks. If the hooks fail, Git will not allow you to enter a message and commit the staged files. This hook is also very useful for running linter tools, such as
swiftlint before committing files, which can prevent style fixup commits later on.
This hook is useful for making sure that commit messages are formatted correctly. Commit message formatting is a large topic by itself, so I won’t get into that too much here. Personally, I’ve based my commit message style on the rules from this blog post and wrote a python script which checks most of these rules.
It’s a good idea to check that your test suite passes before pushing code so that you don’t have to add “Fixed a test” commits or modify history that has been made public. I also use this hook to ensure that I don’t accidentally push any WIP (work in progress) commits, which make the history confusing and cluttered.
Making Git Hooks Easy
Vanilla Git hooks are not super intuitive and can be rather limited. You can only have one script for each type of hook which must be named after the hook. Hooks live in the
.git/hooks/ folder which is not tracked by Git. If you want to track changes to your hooks, you need to symlink the scripts in your repository to the
These limitations frustrated me, so I wrote a tool to make hooks easier to deal with. It is a single shell script that lives in your repository. After you install it, any number of hooks you want to run can be placed in the
.githooks/ directory (which you can track in Git). For example, with the
pre-commit hooks I described earlier, both scripts will be run before a commit if they are placed in
repo/ .githooks/ pre-commit/ check-trailing-whitespace.sh check-newline-at-eof.sh
Stay in the loop with our latest content!
Select the topics you’re interested to receive our new relevant content in your inbox. Don’t worry, we won’t spam you.
Putting a Kettle On: Server-Side Swift with VaporMarch 23, 2020
One of my goals this year is to make a concerted effort to try out Vapor for server development. As a framework for making server applications in Swift, I’ve had my eye on Vapor since the 3.0 beta period many moons ago. The release of Vapor 4 seemed like as good a time as any to dive back in.Read more
Building Better App UI Architecture- Android ThemesJanuary 13, 2020
In the last post, we discussed how do we optimize the UI system implementation by breaking down the design into smaller pieces, identifying the UI elements and components and using protocol-oriented programming in iOS.Read more
Why Your Business Needs to Be In the App Store—YesterdayJanuary 20, 2021
Whether you’re a Fortune 500, a startup, or somewhere in the middle, there are countless reasons to consider developing a mobile smartphone app. From giving customers a more complete brand experience to gaining credibility in the marketplace, here are just a few of the benefits of having an app.Read more