The laws of branching (part 1)
The first law of branching is: don’t. There is no other law.
The only sane way to develop software in a group, whether collocated or distributed, is to have a single branch (“trunk”) to which everyone commits changes, with constant running of the regression test suite to make sure that any breaking change is detected and corrected right away.
To allow branching, that is to say the emergence of separate lines of development with the expectation that they will be merged back later on, is to guarantee disaster. It is easy to diverge, but hard to converge; not only hard, but unpredictable. It can take days, weeks or more to reconcile changes and resolve conflicts, when the reason for the changes is no longer fresh in the developers’ memories, and the developers themselves may even no longer be there. Conflicts should be detected right away, and corrected immediately.
The EiffelStudio development never uses branches. A related development, EVE (Eiffel Verification Environment), maintained at ETH, includes all research tools, and is reconciled every Friday with the EiffelStudio trunk, so it is never allowed to diverge into a separate branch. Most other successful teams I know apply the first law of branching too. Solve conflicts before they have had the time to become conflicts.
Eiffel Software
Home page at ETH
Informatics Europe
LASER summer school
Propulsion Academy
It feels to me like you’re making some sweeping generalizations here, without presenting any evidence. As a professional developer with 20 years of experience, I have seen lots of yucky problems with branching. These problems are typically caused by poor or misaligned mental models in the minds of team members, and you’re correct to warn about them. However, I have also seen branches provide elegant and robust solutions to difficult collaboration problems. Although your first law may be used by most successful dev teams that you know, it is definitely not used by most of the successful dev teams that I know. The rule I’ve seen applied more often on good teams is: understand the implications of branches; use branches carefully and in a way that everyone expects.
Seriously, such generalized statements are just sad.
Version control is a very wide spread topic and branching pops up in many flavors. Saying branching is a guaranteed disaster is simply wrong!
If you choose the right version control software (I’d suggest Git) and make sure to follow certain rules, branching becomes a must.
As an example: You have a master branch, which only the maintainer/lead developer can commit to, thus he’s the “guardian” of the master branch. Every other programmer got access to any branch with their name as a prefix. If I’m not the lead developer, but I want to contribute to the source, I’d go create a new branch locally, work on it for as long as I need to implement my feature. Then before I commit to the public repository, I’ll rebase my branch onto the master, thus guaranteeing that all the new changes on the master, are reflected in my own branch and only then I’ll commit.
The main dev will then check my commit and if everything is okay, it will be merged into the master or rather since it’s rebased, just added to the master.
This is just one way to do it and branching isn’t a disaster here!
The disaster I see with having one branch is either every commit has to be final and non breaking or the single branch is filled with unfinished features, bugs and breaking code.
I hope you get something useful out of part 2, but this post here is beyond generalized and contains about zero reasonable information. Or was this just a ad for your and the ETH software?
> if everything is okay
In this “if” lies the whole question. *Never* is everything OK.
The point is not to defer to popular opinion but to partake of software engineering experience, whether or not it is fashionable.
I think that with a little more experience you will come to renounce branching, like most seasoned developers I know.
“The point is … to partake of software engineering experience …”
But which software engineering experience? Although you’ve summed up quite nicely my own preference for not branching (being of small brain, I have difficulty keeping track of more than one branch per project), the only case that you’ve cited here is EiffelStudio, which is a Subversion repository. Branching and merging are often nominated as Subversion’s weakest point. Branching is much more manageable, by all accounts, with distributed VCSs such as git. I’m sure you must have had more than just the EiffelStudio project in mind when you thought of this law of branching, because it’s easy to find plenty of cases to support it … but on the other hand there are plenty of counter-examples.
Apart from technology (VCS versus DVCS), there are other project variables. For example, how many developers are actively working on the project? Are all developers on the team highly trusted? What regression testing is in place? I gather that the core EiffelStudio team consists of a handful of very experienced people who have been working together for many years on this project, with the benefit of very mature automated integration testing. Such a team is ideal for working in one master branch (or “trunk”, in Subversion-speak). But imagine if there were thirty developers on the team … or if half the team were complete novices … or what if there were no unit tests or contracts … what would happen then? I think the core developers would quickly realise that they needed to take tighter control of the project by some means or other; and one tried and proven way to do this is by moving to a DVCS such as git.
Branching is a sane way of development if you use git’s model of short lived branches.
Hi Bertrand,
I can’t agree with your main statement either. The principle has actually got nothing to do with the tools, although trying to do branching with a bad tool (SVN) will destroy your chances of succeeding. But that’s like trying to do proper inheritance in C++. Inheritance isn’t broken, C++ is.
In order to have any economy of scale, the general situation is multiple teams of developers, maybe distributed, and over time bringing in new developers and also losing long-term staff. There is no way, beyond a very small tight-knit level of team development that variant baselines of the software won’t be needed. Making it work is all down to a) having a clear picture of the structure of the software and b) accordingly being able to know where the teams can be deployed without stepping on each others’ toes.
Additionally, it’s difficult to see how to easily do ‘what-if’ scenarios without branching. We do this all the time, even on single developer projects.
The key is having conscious knowledge of both the software and teams, and channelling changes through appropriate editorial processes. It’s the same logic whether for Linus Torvalds merging in changes that bubble up from the lieutenant level, or a document editor who has to merge in review comments to large documents. If everyone works on the same, trunk line of development, things normally get out of hand very quickly.
The teams at ETH and Eiffel Software are way beyond the skill and cohesion level of normal development – they’re not representative, and theories based on their behaviour won’t be widely applicable.
BTW I meant to add that a law that would make sense is: uncontrolled and unmanaged branching is guaranteed to fail.
Bertrand Meyer:
The idea of avoiding branches is good but “how to still get what is sought” is the crucial point. A few cases of where branches were CONSIDERED unavoidable but are ACTUALLY AVOIDABLE would take us beyond claims into “benefits”.
The statement is bold and controversial but that cannot be the reason to reject it. I want to know how to make it work without taking more trouble than using branches and living with the associated problems.
Best wishes,
There is nothing wrong with branches provided you don’t allow them to live long or you don’t expect to be able to every merge them together again.
A bunch that has a 5 line change to fix a problem a customer is having with V1, while the V2 code is being written, is very different then have two long lived active branches.