11

We are moving our project's team from using a single Main/Trunk branch, to multiple Development/Work branches that should be regularly merged into Main. We're basing our new process on this article and the TFS Branching Guide (we are using TFS and Visual Studio 2010).

There are currently between 1 and 5 people working on the project at any one time. Main must be stable at all times because we want the option to release whenever we need. We don't have fixed sprints - at least not yet - and at the moment release every 1-2 weeks.

Right at this point in time each person is fixing bugs across the application. In a couple of weeks we will be starting development on a new large component for the app.

One sticking point we are finding is when development branches should be created. We will be implementing multiple user stories in parallel depending on the skill set of the developer. We've thought about creating a branch for each developer but that doesn't make sense because there will always be some need for collaboration on a piece of work. We can't get by with a single development branch because we will want to merge to Main while other work is completed.

Does anyone have some guidance on this?

Improve this question
2
  • God bless your soul for using TFS and creating branches. At a previous phase in my company they decided to use TFS, and eventually all the developers became so scared of the merging process that branching turned into Programmer Fear Factor. Commented Sep 6, 2011 at 4:16
  • @Jordan: A not completely unfounded fear. Commented May 1, 2018 at 20:00

5 Answers 5

Reset to default
9

I'm not fond of arbitrary branches i.e. Fred's bugfixes or Harry's bugfixes. I'm much more comfortable with one (independent) feature one branch which allows multiple developers to operate on one feature; but for the feature to be merged only when it's complete.

So, right now you only need the "bugfix" branch but once you start development you should create a branch for every significant feature. That way when they are done they can be merged in & released without being dependent on other buggier functionality.

Not sure how good TFS is at merging but I'm sure you'll know in a few months :)

Improve this answer
1
  • This is pretty close to how we are doing it where I work. If you only make sure to religiously merge from trunk to each working branch whenever changes make it into trunk, it works quite well. Also, look into setting up automated builds at the same time. Knowing that each branch (as stored in source control) is always in at least a buildable state makes things much easier. As for merging using Visual Studio's tools, it works well until you have hugely long lines with changes on both sides of the merge... Commented Sep 6, 2011 at 12:52
5

We can't get by with a single development branch because we will want to merge to Main while other work is completed.

It sounds like you already know that multiple development branches must be created. Two probable scenarios come to mind:

  1. Each of the five developers are working on independent parts of the project (bug-fixing) - Make sure that an individual branch is created for each developer. This places the onus and responsibility onto each developer to make sure their set of changes does not conflict with anyone else's work. It is highly likely that one of your five developer will make a mistake. If/When that's the case, it doesn't make any sense for everyone else to be held up.
  2. Multiple feature developments - Regardless of the number of developers working on a particular feature/bug, these should be separated. An example of this being beneficial is that all code commits are part of the feature(s) being developed - there's no second-guessing involved.
Improve this answer
1

Implied work branches with DVCS

We use Mercurial so there is the implied work branch on the developers dev box. Commit are always done to the local workspace. When a releasable piece of work is completed it is pushed up to the primary repo server where it is automatically built and tested.

We almost never create explicit branches, but then again our sprints are never more than 1 week long and are cards take no more than 1-2 days to complete.

Also, you can mitigate merge pain by threading in work from other parts of code or other projects so people aren't having to do difficult merges all the time.

Improve this answer
0

I have used both single branch per story and one branch per release (all developers check-in their stories to dev and if any of those breaks the dev branch it is broken for all). I would highly recommend the one branch per story if you do not like conflicts. The dev branch will always remain stable for all devs and there will be no wait time for a developer working on a piece of code which another developer broke already. When your story is finished all your code is in your branch. You will merge it to dev but not check-in and test, in case you get conflicts you will resolve it and ask the person with whom are you conflicting to avoid removing his code. Then merge to dev. This helps all devs work smoothly. It also depends on the size of the company. Our company has 200 devs working simultaneously on one code base, but separate branch for their stories. Once the code is merged to dev branch, the story branch is immediately deleted. I hope this helps. Thanks

Improve this answer
0

If this is based on git, then you just create a branch for each bug fix, fix the bug in the shortest possible time, merge the bug fix branch with the development branch, then push the change to the development branch. Reviewing pull requests and merging should be the highest priority, because the quicker you get it done, the better the chances that merging doesn't cause problems. Once merged, these branches can be deleted.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.