git insticts

Here’s a collection of “git instincts” loose guidelines, gut feelings and/or random thoughts on what I tend to keep in the back of my mind while I’m coding and committing changes.

There’s no shame in reverting #

When hunting bugs or delivering a complex feature you might end up changing a lot of things as you venture deeper and deeper into a code base. It can get hard to keep track of all the changes you made and suddenly things starts acting wonky. If you find yourself in a situation like this and you’re fiddling with code to try and restore some sanity the codebase, stop.

Lean on the power tool that git is and do a git revert or git checkout to a recent workable commit. I have a low tolerance for fiddling with code trying to figure out what’s wrong. Don’t be afraid of going all “hail mary” nuking your project (deleting it) and doing a fresh git clone.

Commit early and often #

This does not mean a stream of single word commits containing insignificant changes.

What it does mean is a stream of small commits where each commit represents a significant change. There are a lot of opionions here (mine is just one). Some developers advocate that one should create the smaller commits in a separate “feature-branch” branch before squashing them in yet another branch and finally merging the code as one large commit into the final destination branch.

Personally I try to use git in an unfancy way. I try to make many (reasonably) small commits. And I very rarely squash commits. I also do not try to too hard to avoid merge commits when pushing my changes to the server. I rebase only if it’s easily done. In sum I argue that one should contribute clean sensible commits and accept a less pretty (but more true) commit history.

Don’t be stingy with branches #

Sometimes it makes sense to commit directly to the “main” branch that everyone is working against. Other times it can make more sense to branch out into a new branch.

Reasons include that you sense that it will take many commits to land the feature you’re trying to accomplish. Another reason might be that you sense that the change might be controversial so you push the change as a new branch and create a more formal merge request to have it merged into the main branch. You might also branch out several times because you realize that the branch name did not quite cover the intended feature.

A benefit from working in feature branches is that you can always commit what you have in that branch and jump back to the main branch to bust out some other feature if need be. Then later you can return to the feature branch, rebase it against the main branch to pull in changes and continue work until you finally push it to the server and create a merge request or merge it locally into the main branch and then push it to the server.

Remember that since you’re committing your changes locally there’s always room for yet another branch and nobody will ever know about the branches you did not push. It’s fine to keep old branches around for reference just be sure to tidy up the branches every now and then.

Work on one thing at a time #

This is easier said than done. Imagine your coding some feature and you notice some related service that you can’t help but also work on. And maybe changes to that code necessitates changes to other code and suddenly you’ve touched many files for various reasons.

You’ll discover that this can result in one massive commit with the commit message being a short novel. Alternatively you’ll have to sit and figure out if you can get away with partially committing changes so that you end up with smaller commits that are individually revertable. Beware, if you try to divide a lot of changes into partial commits there can be hidden interdependencies between the changes that will cause breakage if someone decides to revert one or more of the commits.

I often write memos to resist the urge of changing too many things at once. If I’m working on a feature and I realize that some related code should also change (but it’s not that related to what I’m working on) I jot down a quick reminder and return to it later.

All in all it’s easier to try and keep things easy (naively put).

Cover photo by Ronnie Macdonald (licenced under CC-BY).