Thoughts on Branching Patterns

In a recent longread Martin Fowler makes an impression of an article about different ways of organizing source code into branches.

But the truth is that it is really a promotion to use a single way of working with source code described as Release-Ready Mainline. The idea is to write fast-running tests for your code together with your code and commit and merge them together back to mainline (a.k.a origin/master) as often as possible. The tests prove that the mainline is healthy so you get immense freedom in your work – you can release/deploy the product whenever you want and you can branch off of it whenever you want.

And I think this idea is great and striving to do it is an admirable thing.

Also this idea is very simple to comprehend and all the tooling — the Unit-tests and the source-control — is already there for a very long time. So why then Release-Ready Mainline isn’t it rapidly spreading? Naturally the thing that requires less effort substitutes a thing that has more effort.

I don’t know the exact answer for that, but I learned some other things from this article.

Many people ascribe the popularity of Feature Branching to github and the pull-request model which originated in open-source development. … Open-source projects are structured in many different ways, but a common structure is that of a one person, or a small group, that acts as the maintainer doing most of the programming. The maintainer works with a larger group of programmers who are contributors. The maintainer usually doesn’t know the contributors, so has no sense of the quality of the code they contribute. The maintainer also has little certainty about how much time the contributors will actually put into the work alone, let alone how effective they are at getting things done.

But many commercial software teams have a very different working context. There’s a full-time team of people, all of which commit substantial, usually full-time, to the software. The leaders of the project know these people well (other than when they just start) and can have a reliable expectation of code quality and ability to deliver. Since they are paid employees, the leaders also have greater control about time put into the project and on such things as coding standards and group habits.

This is an interesting notion — don’t blindly copy everything from the OSS development process.

This also means that for instance the Code Review can be removed in a commercial software development process. And that could speed up the whole flow (you don’t need to wait for someone else’s looking at your code). Valid point.

For me however the Code Review is still very valuable because it allows to learn the best practices. It takes time; it forces you to switch context; maybe you’ll have to put away your current work and come back to fix the things someone noticed in your Pull Request. Those are the downsides. The upside is that by creating a PR and requesting a review you present your code and you get a good way to learn the obvious little improvements and eliminate the obvious little bugs. Also by looking at other reviews you can learn as well.

This is the biggest point of conflicts. Senior developers think they know already the best way of doing things and for them the reviews are a nuisance (sometimes they are right, sometimes they aren’t). New developers usually would like to have their Pull Requests reviewed to be sure they haven’t reinvented the wheel or created some obvious security hole or something similar.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.