Application Architecture with SwiftUI
June 15, 2022An overview of mobile application system architecture using SwiftUI
Read moreAt 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
whitespace
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:
pre-commit
)commit-msg
)pre-push
)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 pep8
, checkstyle
, or 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.
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 .git/hooks/
directory.
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 .githooks/pre-commit/
:
repo/
.githooks/
pre-commit/
check-trailing-whitespace.sh
check-newline-at-eof.sh
Please check out the examples for more useful Git hooks and send me your own if you have more ideas!
Looking for more like this?
Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.
An overview of mobile application system architecture using SwiftUI
Read moreOne of our Associate Software Developers, Rohit, reflects on his time at MichiganLabs working on a short-term project, what he learned about real-world development, and the software consultancy business model.
Read moreDavid shares how easy it is to create your own AI art generating Slack bot using Typescript and Stable Diffusion.
Read more