I would strongly recommend that you run a controlled comparative trial to find out which way is better for your project instead of wasting efforts and ruining team communication on fruitless “theoretical” debates.

In one of my past projects we wasted time like that for more than a year until we decided to do such a trial run. First, we run it for a few months, carefully tracking time spent on branching made the “established” way. Then, we spent few months running and tracking “alternative” approach.

After completion of our comparison, we simply studied results of tracking and have chosen the way that looked less effort consuming (if memory serves, we had about 4 hours a week average per developer using one way versus 0.5 for another way). No debates, no hurt feelings, just business. People get objective numbers, compare and make informed decision, it is that simple.

This will prove difficult… I can’t imagine an objective way to reconcile this.

Well in our case it wasn’t really difficult. It likely looks difficult the same way as it is difficult to debate branching approaches differences “theoretically”. When running the real trial, all this broad stuff magically gets split into small, concrete, manageable use cases that are much much easier to evaluate.

Things worth keeping in mind is that 1) few months mentioned above were proven sufficient to carefully evaluate efforts supposed to be related to one or other approach and 2) while trial is running, it is most important to just carefully write down stuff, leaving discussions on it to be dealt with separately. It was like,

• “spent one hour integrating with half-baked component change committed by John”
  goes to ticket labeled branching-strategy-1
• “spent one hour investigating the bug introduced in recent branch merge from Paul”
  goes to ticket labeled branching-strategy-2

At the end of the trial, this data is “extracted” from issue tracker, discussed and clarified. Results are exported to Excel, difference is calculated and preference is made based on that.

It is really important here that teammates record anything that looks like maybe related, because if not recorded, data that is maybe important is lost. As opposed to that, for the data that is recorded, it’s not difficult to drop out the stuff that deemed irrelevant in a more thorough discussion at retrospective analysis.

• ^{…And yes, in our trial we dropped some records that way, …and no, there was no heated debate there, because 1) this was all about discussing real, concrete use cases, practical and material up to point of feeling quite strategy agnostic. And because 2) the team was interested in finding the way that saves our efforts for more interesting stuff rather than in religious debates on whether to branch or not to branch.}

This somewhat resembles a Postel’s law (aka robustness principle),

be conservative in what you do, be liberal in what you accept from others

As for situations where Branching is a bad idea, well when preparing trial run mentioned above we studied available information (summarized in another answer at Programmers) – just to find out if maybe we can avoid spending few months on running the comparative trials.

From what we learned back then, the answer is “it depends on the project”:

there’s no commonly agreed “best” branching strategy applicable to any project

• most resources seem to agree that choosing productive strategy depends on the particular project specifics

• side note. Based on above it looks like any changes to project branching strategy need to be tested, measured and compared to other options tested…

The question is awfully general – I can say, with some assurance, that there is ALWAYS some situation where X is a bad idea, no matter how good an idea X is normally.

Your co-worker is clinging to a view that was NECESSARY back in the day, when good source control and merge tools did not exist. He essentially doesn’t believe that merging can work on a day-to-day basis.

Less than 5 years ago, I worked with some people who insisted on locking checkouts (you had to checkout before editing, and only one person could check a file out at a time) because they just couldn’t understand that merging was possible and worked just fine.

The question is: WHY does your co-worker not believe in merging? I’ve believed in it ever since I first saw it work in CVS many moons ago.

My guess is that there is something in how you are operating that is causing merge problems, and your co-worker can’t see that it’s possible due to some operational issue on your team’s part. Until you figure out what that is, you’re never going to convince him.

My personal experience with this is that training will help in this cases.

I had the same problem (with SVN) with co-workers. After training my co-workers one project group (where I was not member of) only developed on branches after that never on trunk.

The most important thing in training is that merging (and conflicts during that) are normal and no exception. If your co-workers lose the fear to merge and having conflicts (because this is normal) then after some time the situation should clear.

Well, more branches implies more complexity. Imagine your software grows, the team grows, time passes… I think the main issue is dealing with merging and conflicts if the branches start to diverge too much and people work parallely on them.

Stupid example: we had two big branches, with changes in overlapping areas, and a guy had the super smart idea to change all tabs to spaces on trunk …arrrrghh …the merging was a nightmare. Actually, the merging tool didn’t even cope with it correctly, so in the end, I “not merged” thousands of lines one-by-one by hand.

Additionally, when time passes, you’ve to keep track of what is in what, which one is still active, which one not, if some branch stays inactive too long, it becomes harder to merge, or perhaps someone will forget a mini-fix while resolving a conflict, etc.

I guess, in the end, it’s all a question about the right balance. Make a branch when you need to, but don’t make them “just for fun”. I would also tend to easier make a branch with Git or Mercurial than I would with SVN, they are easier and more flexible when dealing with branches while SVN has several times been a PITA for me. So I guess it depends on what you use as well …but less branches usually makes life easier.

I think you’ve answered your own question

we have issues with merging. I argue the root cause of these issues are a lack team
communication and a lack of knowledge on how to correctly use our source control system 
to full effect (TFS).

If your team isn’t communicating as well as it could then having code in branches or in separate little projects doesn’t really matter. That said in your comments you’re talking about giving people the opportunity to learn more about this tool/option, and that’s got to be a good thing. Branching is like any tool, it can be really useful it can also be abused.

At my current place we don’t use branching, not through choice mainly because we are so small, and there’s lots of other things we need to put in place first. If we did have branching we could write more patches, do more prototypes and merge back into the main code base.

I think Branching could cause a problem if ignored and allowed to get out of hand. Like anything that grows via branches, a bit of pruning won’t do any harm.

I believe that the core of the question has to do with merging not branching. I believe what worries your supervisor is merging back (most common case as well as it derives from your question). This after git made it easy to merge (“IT DOES NOT MATTER HOW EASY IT IS TO BRANCH, ONLY HOW EASY IT IS TO MERGE” – Lunus Torvalds), has propagated to most Version Control Systems.

The brain does not help but to regress to previous experiences. It seems that last time your colleague checked on the issue, the available solutions were not at a good level. Therefore he devised a workaround (the mini projects) and forgot to check again, say five years later. Very common, specially when people move to middle management.

Even the best ideas can be taken to a ridiculous extreme. While most versioning systems can handle lots of branches without issues, the problem would be on the human end, as you end up getting lost on which branch belongs to whom, was the branch to be worked on later or to be made inactive, etc.