When I started as the first employee at Burstworks, the cofounders and I could easily hold the information about who was working on what at any given moment in our brains.
But as we worked on new projects and the scope and size of the engineering team grew, all of our code mostly stayed organized in one central repository:
- Our high-performance ad server
- Data Pipeline
- One-off scripts
- Nightly jobs
While we generally weren’t working on the exact same files at the same time, there was still lots of stepping on toes. Having your
git push rejected was a common occurrence.
Inevitably we had issues with merge conflicts, which lead me to send this tweet from our company account:
— Burstworks (@burstworks) July 2, 2014
And so I decided to take a step back and think about how we managed our version control system at Burstworks.
I definitely didn’t want to come up with something heavy handed or overly-proscriptive. The goal was to come up with just enough process to grease the wheels, and not slow things down.
I did some reading, came up with some initial ideas and pitched them to the team. We iterated a bit and here’s what we came up with.
I should start out by saying that it’s nothing revolutionary or new. It’s what I would consider the Minimum Viable Git Best Practices™ for a small engineering organization.