branching and merging strategies

[marcmeans]

I'm newer to the DVCS model of branching and merging. Most of my experience has been around the sequential model of CVS/Subversion. I am familiar with Git/Mercurial and am looking at plastic. I'm still struggling to find a decent explanation of how to approach the branch per feature workflow. My goal is to understand it well enough that I can teach the topic to my team.

I'm going to lay some questions out, I believe I understand the answers to some of them, but would rather have a fresh answer than the assumption I have behind them.

1. For a smaller team that is used to working in a sequential style repository, why would I want to move to branches? We only release when all the planned features are released anyway.

2. If I branch and have dependencies in my branch that another developer needs to work with for their story, how do we share that code and cleanly merge it back to the main line?

3. Should we be merging each feature back to mainline once it's complete, or having an integration developer pull those changes into mainline? If we're moving to a new sprint, how do we ensure we're working on the latest code base going forward?

4. (More specific to plastic) Once i've branched and merged for a few months and have a branch explorer that looks like a large tangle, is there a way to isolate the explorer so we can 'ignore' the past visually and focus on the last few sprints and upcoming work?

Thanks in advance for anyone who can chime in.

Marc

[carpediemevive]

1) You wouldn't. It makes much more sense to branch per release in your instance. What branching per task/feature allows you to do is to release much more frequently. In fact, you can release anytime as long as one feature is at least complete. It can be quite liberating when you try it out, so I'd suggest once your comfortable with the tool try the process out and see if you/your team likes the freedom it buys you.

2) I have two approaches to this. If the features are linked in my bug tracking system, then I'm not going to release one independently of the other and I let them merge as they will. If they want to just try out their changes with the intention of throwing that merge away I would have them create a temporary build branch based on one's code and merge the other code into that. There they can test it/see it and get rid of it without effecting anyone's task.

3) It doesn't matter who merges the code back to mainline, as long as you recognize this is a separate endeavor from any of the other tasks. If you have a person solely dedicated as an integration manager, that person is probably well suited for the job. I just always do it as the last step on a release.

4) The branch explorer has some fantastic visual features. To answer your questions specifically, yes it has a date filter to allow you to view any chunk of time you so wish. You're also able to do some basic layout of the branches to make things look better visually.

[manu]

1) You should move to branches due to you are going to increase your productivity and minimize the project risk. The productivity is going to be increases because every developer is going to work isolated you are not going to check if someone is touching the same code or you need to update. You are going to minimize the risk due to you will get a clean base line instead of having the fear about if the next changeset is going to break the development line.

2) You can use the cherry pick system to incorporate those changes into your working branch or you can also create a shelve and apply it on your branch.

3) I do encourage you to have a person in charge of integrating all the pending tasks. You can release one time per sprint or even more often, 3 or 4 per sprint (2 weeks). Once all the tasks are integrated and the release working you have to label the release changeset and all developers can perform a rebase from this new label.

4) The branch explorer has a date filter, so you can be focused on the branches/changesets created for example in the last 2 weeks.