Next & Previous

Approaches to Version Control

Apart from using different technologies, different people and companies take a different approach to how they employ version control. I want to talk about a couple of patterns very briefly.

Before we begin

The SVN term “trunk” is essentially equivalent to the git term “master”. In SVN, there is a distinction between Trunk and the Branches, but in git, everything’s a branch and all branches are equal.

1. Releasable Trunk (the “GitHub flow”)

“Everyone works on a branch, and the master is always deployable”

Introduced and popularised by GitHub, the GitHub Flow says:

This relies on the review step, because you can’t push something into production if it hasn’t been reviewed and unit tested. So in a contemporary version of this flow, a bot will run the unit test suite against the pull request.

I like this flow because:

How it applies to SVN

It’s the same as long as you have a way of reviewing code. And since you can use SVN tools as an interface onto git, you can actually do this whole flow against a git repo and believe you’re using SVN.

There is only one way that I have found for people to lose work in SVN, and it happens when everyone works on the trunk. Feature branches are important because it allows you to check in your work regularly and privately, without fear of messing up or being messed up by anyone. Merges are a lot easier than you think.

2. Production Branches

“Everyone works on the trunk, and the Live branch is always deployable”

This is another approach I regularly experience. The repository is set up with Branches for Live, Staging, etc. When somebody wants to deploy to them, they merge across trunk changes into that branch. At this point, the CI/CD server builds the branch and runs automated tests against it. When this passes, somebody can trigger a release. In my experience, there are some manual steps after triggerin the release, but it’s possible to eliminate them with good enough process.

The perceived advantage of this approach is that you rarely have to merge, and everyone always has the latest version of the code. In reality, you merge every time you update, but because your trunk changes aren’t checked in anywhere, you gain the neat ability of completely losing them. See my note above.

The disadvantages are:


You can probably tell which of these I prefer. There is a wider question about how viable the GitHub flow is outside of GitHub, but there are other tools to enable that flow in other systems, and it’s mostly a question of process.