This branching thing.
The idea behind branching is that it provides advantages in situations where a code change is large. The idea behind non-branching is not to enter those situations. These two views seem very difficult to reconcile.
I am a non-brancher. I push to head, I pull from head, I test on head, I ship from head.
Let’s take a second to consider the arguments against living like this.
First, a whole team that lives like this is constantly merging out and merging in, and that feels expensive. My counter is to point out that, as we learned with continuous integration, higher frequency of merges means far less pain.
Second, ongoing large-scale changes are always partially in the code long before they are ready for prime time, i.e. Release. There is a technique price for this, to be sure. But there is also a substantial gain from using those techniques.
The price is that you have to learn and use the various ways to prevent parts of head from being exposed to the user. These include things from feature-toggling to code re-organization, with many small patterns mixed in, like strategy and abstract factory. It’s a lot of technique to learn, and hence the price. (i know of orgs who try to solve all this with one technique, but it doesn’t work.) but the gain comes in two parts. Overall skill, and longer periods of GAK and other alpha testing.
What I mean by overall skill: these techniques I mentioned are not special cases only for this end, they’re the meat & potatoes of coding. Abstract factory, say, or strategy, these are techniques that have myriad applications in programming aside from hiding code from users. So my geeks will use exactly the same proficiencies they should already have, and if they don’t know them, they should be learning them.
The longer periods of GAK and other testing is the second gain. (GAK = "Geek At Keyboard", a geepawism.) the longer the code is in the base, the more likely we all are to discover infelicities before we get to release. This is of great value.
A third critique of living branchlessly is that it doesn’t let us hierarchicalize — org-chart-ify — testing & development & auditing. Here we meet the ol’ geepaw at his most annoying: "that’s not a critique." the separation of responsibilities idea was always classic idols of the schema. Looks good on powerpoint, does not work well at all.
The fourth critique of non-branching is a kind of protean thing, whose rough gist is the fear of shipping defects. You’ve already seen one counter, the idea that the longer code is in place the more defects we can find in it. But the real counter has to match the protean nature of the fear. It’s amorphous, attitudinal, and involves a huge variety of cases.
In one sentence: you get fewer defects by writing code in a defect-revealing way, not by trapping them after the fact.
When we ship a defect in the non-branching world, we respond to it in steps designed to disable that kind of defect forevermore. We don’t fix the defect and keep moving. That’s about attitude and technique both, a typical sociotechnical response.
I understand that’s a vague answer. It was a vague question. The truth of the matter is that that fear is based on a false abstraction. You can’t divide the world into bugs & non-bugs, or more correctly, you can, but it’s too abstract. Real bugs have great variety.
The actual branchless response to discovering a bug depends on the nature of that particular bug & its family. If you want specific answers to how do I prevent bugs of family X, we need more info about that family. To pretend otherwise is bogus. In fact, pretending that all bugs are alike is precisely what creates that amorphous fear in the first place.
I’ve gone on too long already. Let’s wrap this…
Branchless living is suspect on four grounds: merge inefficiency, partial implementations, org-chart-lessness, and defect fear.
Merge inefficiency doesn’t match our experience. Partial implementation is just part of programming, org-chart-lessness is a good correction. Defect fear is based on a weak abstraction.
I live without branches. I recommend strongly that everyone do so. Key insight: don’t make large code changes, and you won’t need branches.!’