Times do happen, where one would write code that should please, please not land in the production release, like for example:
- Overwriting a certain URL with a local one
- Having a dialog always-open in order to efficiently style it
- or generally, mocking code of something that is not-important-right-now™
And then we all already know that such shortcuts tend to stay in the code longer than intended. One might tell oneself:
Oh, I will mark this as // TODO: Remove ASAP
This is the feature branch, so either me or the Code Review will catch it when merging on main.
And this is better than nothing – some Git clients might disallow you from even committing code with any //TODO, but I feel that this is direct violation of the idea of “Commit Early, Commit Often”. As in, now you’re bound to finish your feature before you commit. This is the opposite of helping. By now you figure:
Thanks for nothing, I will just rename this as // TO_REMOVE
Rest of above logic applies untampered with.
These keyword-in-comments are sometimes called Code Tags (e.g. here), and here we just worked around the point that //TODO is more commonly used than other tags, but of course, these still are comments of no specific meaning.
You might now be able to push again, but still – say, the Code Reviewer does the heinous mistake of trusting you too much – this might lead to code in the official release that behaves so silly that it just makes every customer question your mental sanity, or worse.
Git Hooks can help you with appearing more sane than you are.
These are bash scripts in your specific repository instance (i.e. your local clone, or the server copy, individually) to run at specific points in the Git workflow.
For our particular use case, two hooks are of interest:
- A pre-receive hook run on the server-side repository instance that can prevent the main branch from receiving your dumb development code. This sounds more rigid, but you need access to the server hosting the (bare) repository.
- A pre-push hook run on your local repository instance that can prevent you from pushing your toxic waste to the branch in question. Keep in mind that if you do your merging unto main via GitLab Merge Requests etc. that this hook will not run then – but implementing it is easier because you already have all the access.
The local pre-push hook is as simple as adding a file named pre-push in the .git/hooks subfolder. It needs to be executable – (which, under Windows, you can use e.g. Git Bash for.)
cd $repositoryPath/.git/hooks
touch pre-push
chmod +x pre-pushAnd it contains:
#!/bin/sh
while read localRef localHash remoteRef remoteHash; do
if [[ "$remoteRef" == "refs/heads/main" ]]; then
for commit in $(git rev-list $remoteHash..$localHash); do
if git grep -n "// REMOVE_ME" $commit; then
echo "REJECTED: Commit contains REMOVE_ME tag!"
exit 1
fi
done
fi
doneThis already will then lead git push to fail with output like
2f5da72ae9fd85bb5d64c03171c9a8f248b4865f:src/DevelopmentStuff.js:65: // REMOVE_ME: temporary override for database URL
REJECTED: Commit contains REMOVE_ME tag!
failed to push some refs to '...'
and if that REMOVE_ME is removed, the push goes through.
Some comments:
- You can easily extend this to multiple branches with the regex condition:
if [[ "$remoteRef" =~ /(main|release|whatever)$ ]]; - The
git grep -nflag is there for printing out the offending line number. - You can make this more convenient with
git grep -En "//\s*REMOVE_ME", i.e. allowing an arbitrary number of whitespace between the//and the tag. - The surrounding loop structure:
while read localRef localHash remoteRef remoteHash;
is exactly matching the way git is processing this pre-push hook. Each hook has awhile read <arg list>structure, but the specific arguments depend on the actual hook type.
Hope this can help you taking some extra care!
However, remember that for these local hooks, every developer has to setup them for themselves; they are not pushed to the server instance – but implementing a pre-receive hook there is the topic for a future blog post.
Schneide Blog 