Origin story
It’s 2012. I’ve just joined my first startup, and I sit right next to the desk of one of the founders. The company has started the [long] journey to adopting microservices, but my team is still working on the monolith. The “cool kids” are using Git, but we’re still stuck on TFS.
Every month, a couple of the founders get together for “merge day”. Back then, the company had two versions of the codebase: one for their SaaS offering, and another (customized) for a big client to run on-premises. Because these versions were developed by different teams, they had to keep improvements and bug fixes in sync. The way to do this was to regularly merge one long-running branch into another.
As you can expect, there are conflicts. So. Many. Conflicts.
Becoming an expert
I had used Git for personal projects for a few years, but I didn’t quite get how it was different from SVN or CVS. Things started to “click” after I read the excellent Git from the Bottom Up1. But I was still lacking that practical experience.
One day, I casually mentioned to a founder that we should migrate the monolith repository from TFS to Git because it was “better at handling conflicts”. To my surprise, they told me to just do it. Little did I know that I had just signed up for “merge day”.
It’s funny how you can become an overnight expert on something just for bringing it up. I was suddenly “the Git guy”. The more I was summoned to help with a Git problem, the more I learned about it. I was in a positive feedback loop.
Seeing a pattern
Fast-forward a few years, and I became an advocate for rebasing and using the Git CLI (especially the interactive mode, available on different commands).
However, as I joined different teams and companies, I noticed people were still using Git as a centralized VCS. They struggled to deal with ordinary things like merge conflicts, which often led to the “inexplicable” loss of files and changes. Instead of using a powerful tool to their advantage, they were creating convoluted processes to avoid falling into common traps.
Given enough time, I was repeatedly able to “convert” coworkers (and beyond) to a simpler way of using Git. None of them ever went back to their old ways. If fact, many thanked me for introducing them to these practices, sometimes years after we had worked together. This gave me confidence that I needed to share my experience more widely.
Sharing with the world
Over the years, I’ve done several talks on Git and ran a few workshops as part of my Practical Git2 series. I’ve contemplated writing a book on Git for a long time — I even took the Effective Book Authoring course last year. But the feedback loop always felt too long.
Instead, I’ve decided to create this Substack. I’m not exactly sure what the end product will look like, but I’m excited about the creative freedom and possibilities the platform has to offer. I want the content in here to feel like it’s coming from a coworker, so this is the tone I’ll adopt throughout. I’ll commit to writing at least once a week.
Thanks for joining me for the ride! Let’s get Gitting.
It turns out that Git from the Bottom Up has been ported to GitHub since I read it back in the 2010s. However, I was nostalgically happy to find that the original text is still available.
The name Practical Git is a shameless steal from Practical Vim, a book that changed the way I use Vim.