Bob Browning's blog

I’ve written before about my reservations with Git. This is the story of how those reservations played out in practice — and what I should have done differently.

Coming back to coding after years away, I accepted Git because that’s what our contractors used. The original plan was sensible enough: each job gets a branch, I test it, it gets merged into main, and we release. But in practice, many jobs were tiny — a few lines of code — and the branching overhead felt disproportionate. So we improvised: a single development branch where work would accumulate, and I’d test a batch of changes before releasing.

That improvisation is where the trouble started.

By the time we were ready to release, development and main had diverged significantly. I tested development and signed it off — but I was signing off on the wrong thing. In Git, you test main after the merge, not the branch before it. When I asked for the merge and release, I received this:

“Hi Bob — merge could be risky and we can’t take responsibility for managing conflicts, as you are the owner of the code.”

The release would be stalled for several days. I had promised the investors a release date and we were already late. In the end I released development directly to the live site and deferred the merge question to the following week.

So what actually went wrong?

I didn’t understand Git’s philosophy — and that’s on me.

Had I understood it, the answer to “what do I do with lots of small jobs” was straightforward: commit directly to main for minor changes, test main periodically, and release from main. No long-lived development branch, no accumulated divergence, no merge anxiety at release time.

The development branch felt like a pragmatic solution at the time. In reality it was a workaround for not understanding the tool — and it created exactly the kind of problem Git’s workflow is designed to prevent.

The rule I’m taking away

From now on, I only test main. Whatever the contractors need to do to get their work into main is their process to manage. My job is to test what will actually go live.

It sounds obvious in hindsight. It wasn’t obvious to me because I was treating Git branches as a filing system rather than understanding that a branch only has meaning once it’s been integrated back into main.

The broader question

This experience has made me reflect on whether Git is the right tool for a project of this nature. Git was designed for large, distributed, open-source projects. For a small, tightly managed team, the workflow carries real overhead — and if the person running the process doesn’t fully understand the philosophy, that overhead compounds quickly. I am now convinced that SVN would work better for a small team with an involved project manager. .