10/03/2008
I hate branches. I think that branches are a bad solution for a stinking situation.
now before you I get jumped, I’m aware that there are cases in which branches are a perfectly legitimate solution to a given situation, but still my advice would be to try looking at what is causing the need for the branch, in my experience there is an underlying problem that the branch will not solve.
In the Last Alt .NET gathering I had a very nice discussion with Ken Egozi regarding branches. In that discussion ken and I represented the two opposites approaches. Ken on one hand is using Git and relies heavily on its great branching ability. To the point (if I understood him correctly) that he treat each source change as a different branch. I on the other hand uses SVN and try to avoid branches as much as I can.
During the last year I have used branches three times, in all of those cases I’ve came to realize that the branching was just a mechanism that allowed my to ignore the real issues but just caused us to waste time and effort. Here are the stories behind those branches:
Branching to sustain Quality
I think this is the most common use of a branch. During our development we reached a stage in which we felt that between solving defects and trying to add new features, we couldn't keep our code quality high enough. Preventing us from releasing in our desired rate (about once every 2 weeks). So we branched. Like many other project I’ve seen we thought to use he branch as our release base on which we would solve defects. leaving us to implement new features over the the main trunk.
quite simple right?
Well not really. after trying that for a while we found out that we were always merging all defect fixes from branch to trunk (as expected) AS WELL as all changes from trunk to branch!!!
when facing reality, each new feature we worked on was important enough and it was finished the business side opted to merge it into the branch so we could release it as soon as possible. The result of course was that the trunk and branch were practically identical. We just wasted time merging between the two code lines without addressing the real quality issues.
Branching To fend off a feature
Just before a trip our “customer” has insisted on implementing a couple of features in the last moment for “demonstration” purposes. Those features were quite controversial and we really didn’t want to implement them as they were especially on such a short notice (in fact we had quite an argument on how those should look). However since the “customer” was quite insisting, we choose to implement them on a branch, hoping to discard the branch at the end of the trip. We really wanted to sit down and do a proper decision on those features.
Naturally, at the end, those features were merged as is immediately after the trip, and all attempts to resist that merge failed.
Branching To avoid completing a feature
My latest experience with a branch was caused by me leaving. As part of my final days I was charged to complete a task I already started a task which is just the first step in a series of improvements which are long over due. When finishing the task, since no one actually knew how things will progress from here it was decided to put the task changes into a branch. putting it on a branch should allow picking them up later.
I myself am very much in doubt. I would say that most likely this branch will continue to exists and will never be used again. A branch in this case is just an excuse for putting this work aside still having a false sense of confidence that this can be picked up again. In fact unless those changes will be continued quite soon, they will be so much harder to pick in the future so they will never be completed.
These were my experiences with branching. In retrospect all these branches were just Mistakes on my part. In the first case instead of dealing with the causes for quality decline I tried to shove them aside into a branch. In the second instead of accepting the decision I tried using a branch to fend it off and last instead of admitting reality again a branch is used.
I would really much like to hear about you experience in using branches. Is the dislike I have towards them is just my own or do people out there share this.
Posted in: 
Posts
18 comments:
There is a legitimate use of a branch that you have not covered: to add a feature that will cause massive disruption to a codebase without affecting work done by others.
At my company, we decided to change the underlying way we represented model objects that were used throughout the application. This was a change that ended up taking two of us about a month to implement. Our team, however, consisted of four people, all of whom could not productively work on this one task. Since the change we were making was orthogonal to the other tasks, our co-workers worked on other features in the old codebase while we made the necessary changes in the branch.
At the end of the month, we spent three days merging the branch into trunk and testing the new codebase, and we've been using the new system ever since. I think this is the most legitimate use of a branch: to complete a very disruptive upgrade that will take a long time to implement while allowing other members of the team to continue working.
Alexandros
I think the fear of branches is due to the revision control system you are using. In a DVCS, its the norm to make branches for small changes as it gives you free reign to try out different things on a sterile place that won't affect the mainline, yet give you a way to track minute changes along the way. Merging is usually a snap with newer tools, though when I was using SVN it was always such a pain.
I agree second commenter. In Git merging is painless process but with SVN I try to avoid branching and merging.
subversion users hate branching cause subversion sucks at merging. Learn git.
Alexandros: actually I think that my first example is quite similar to your case.
But lets take your example to its extreme. Why not branch for something that takes a week to complete? In fact why not branch for something that takes a day?
Although your example is quite a common scenario, which I have encountered several times. I would say that the real underlying issue is that you have a feature that take that long to complete.
If it was up to me, I would have split that feature into several smaller ones, (each a few days long). I would commit each part seperately making sure it does not dissrupt the bas codeline.
That way I would have saved the 3 days merge at the end. (which may not look as much, but assuming 20 days a month consists of 15% waste).
Actually no, I don't think it relates to my source control system. I still think that branching out for an extended period of time is not a good practice. In my experience its just a source for waste. Working with GIT or any other similar system just reduce the amount of waste, making the temptation to branch harder to resist.
Regarding branches with short lives (a couple of days at the most). I usually use my hard drive for those (keeping several "branches" on the disk). For me this work but YMMV.
Using GIT or any other similar system would probably do the trick as well, but so far i haven't felt the need for doing that.
First, you use SVN, which has horribly scarred you with respect to branches. Try using git or hg for a while without trying to make them be subversion. Actually use them the way they're intended to be used, and you will understand things about branching that people find hard to explain. Second, your complaints about branches are that they didn't *seem* useful. But what happens if something on the maintenance branch has a huge regression or performance hit? You don't want something like that going into mainline. I think you're being a little short-sighted here, just like Fowler is. Branching is good; maybe not in all use cases, but it is good.
Lior,
Sometimes, it's impossible to divide the task into small, coherent bits, and even if it's not impossible, it's actually harder to do than to just branch.
In the case that I described, we were correcting what for all intents and purposes was a design error---we had chosen the wrong tool early on, and had to switch tools midway. You make the point that you tended to use branches in situations that would not have arisen if things had been designed (or done) properly early on, and at least in my case, you're right. On the other hand, mistakes will always happen, as will unexpected shifted direction for a project. IMO, branches give a clean way of handling that with as little disruption as possible.
I can't really weigh in on the git-svn debate, as I've just barely started toying with git, so I can't quite compare yet.
Alexandros
Alexandros,
In retrospect, my usage of branches was a bad choice that allowed me to avoid addressing the real problem. My advice today would be to seek better alternatives before resorting to a long term code branch. After doing that a couple of times i hope I've learned my mistake. I'm not completely ruling out branches, I'm just saying that in most cases (I have seen), there was a better option.
Without knowing your case (so i may be completely wrong), I find it hard to believe that you couldn't find some way to divide the task into smaller pieces. However Avoiding "Big" feature is is believe a subject for a post on its own.
I don't think I'm too "scarred" by SVN. While merging and branching in SVN can be a little confusion, I have seen much worse.
but since Ive never really tried GIT my point of reference might be completely wrong. So I'll bite and try using GIT for some time see what I can learn.
However, my question to you would be: Why would I ever commit (to the main trunk or to a branch) code that I know will cause hugh regression or performance hit?
My aim is to always but always commit code that I judge as release ready!
Ive regretted every time i broke this rule.
I'm sorry, but your issues with branching are rooted in the fact that you refuse to use them properly. (Or you let yourself be pushed by the customer)
Of course a branch doesn't make any sense if you undo its benefits for political reasons. (I.e. because the customer pressured you)
So even your "branches are no good" approach still papers over the actual problem - you have no or little control over your development process.
Robert,
That is exactly my point!
I have used branching trying to solve things a branch cant solve.
Using a branch cant solve differences of opinion with the "customer".
My "no branch" approach reflect the fact that every time I used a branch there was such an problem that I didn't solve.
When you use a branch, are you sure there is no underlying issue left unattended?
What do you call a "proper" use for branch?
On a side note, under agile methodologies its normal for the "customer" to have a final say on WHAT is being developed.
(same anonymous as the 'scarred' comment above)
The point of branching is to get the benefits of VCS for code that isn't ready yet. Maybe today you code yourself down a rabbit hole, how do you back out if you don't have it under version control? How do you go back after you've deleted the rabbit-hole code and get the good parts of it back? Obviously you don't want to put this rabbit-hole nonsense in the mainline. But once the idea works great, you may want to. And at that point, merging the branches will hopefully be easy. If you don't notice the fact that you're using branches (because it's not painless), then you're doing it right.
By analogy: if your computers run smoothly, you don't notice that IT exists. So by your token, if it doesn't *seem* important, why not get rid of IT?
Spend some time with git, use 'topic branches', and best of all, look at how the kernel uses branches. If you get a feel for how a big, successful project does it, you can apply the relevant bits in your smaller projects.
As for examples where branches *have* been useful for my company in the past:
* Large-scale refactorings or even re-writes of entire subsystems
* Stabilizing APIs for communication - both teams agree on a set of APIs and work with that. At the same time, new features go on in a branch and can modify the API
* Freeze features for a demo
* Independent development of new features.
All of those *did* require buy-in from the customer, though. So I'd say branches are indeed useful - if all stateholders agree to treat them as completely separate.
"Scarred" anonymous:
I would argue that in general I'm not coding "throw-able" code. code which is committed to my source control is always aimed to be "releasable". There are time in which i code stuff for the sake of learning/investigation (the general term used for this is Spike). but at the end of such a phase the resulting code is always thrown away.
Robert:
Lets see:
Large scale refactoring - I try to avoid those as well. Doing "large scale" is a risky business for me. I much more of a series of "small scale" to achieve a big effect kind of guy. In any case I think that we can both agree that if you NEED a big rewrite then most likely something wrong has happened along the way.
Stabilizing APIs for communication - I'm not sure I understood you on this.
Freeze features for a demo - thats not a real branch (in the sense that it is not a live one in which changes are done on). In SVN this will be termed a tag (which is something else).
Independent development of new features - Why would I want those?
I thought that the whole idea of a SCM was to allow independent development on the same source line. (a reminder - in "my book" no half baked code is ever committed to the code base)
@Lior: I do branch for any development. even something that will probably take a few hours and involve just a couple of source files.
What I gain:
a. All of my work is reversible at any point. I have a full fledged history control over by feature development on my local machine. Even when offline (on a train / flight / non-internet grandma weekend)
b. I can push my changes to the central repository and then continue work on a different machine if I like to, one cmdline away. So I can switch from laptop to desktop and back, keeping all history. It also serves as some kind of a catastrophe insurance.
c. I can easily consult with someone who's not standing near me. I just push my work, my co-worker fetches it, and I can get immediate insight.
What it costs me:
Using git - next to nothing.
definitely not "three days at the end of the month". more like three minutes.
Lior,
Great blog posting! I talk about some of the positives of branching and responded to your comments at http://blogs.msdn.com/progressive_development/archive/2009/03/03/motley-says-branches-are-for-trees-not-source-code.aspx.
I think when used pragmatically, branches are a good tool to have in your toolbox. They do not solve every problem and should not be used as a blanket tool for every team.
Post a Comment