Re: Sanity Check: scrum teams, shared 'story branches', rebasing shared branches

[Heiko Voigt <hvoigt@hvoigt.net>]

Hi,

On Sat, Jun 09, 2012 at 04:51:28PM -0700, Christofer Jennings wrote:
> I've been using Git and GitHub for ~6 months. Working on a SCM plan
> for a Scrum project with 50+ developers in ~8 dev. teams. Each team
> will be working on one or two stories simultaneously, so expect ~16
> 'story branches' (and master) at any given time. We've got GitHub
> Enterprise and are working out how to manage story development on
> shared branches that get merged to master only after going through
> acceptance & peer review. We hope stories will only be 3 - 5 days to
> complete, but may take 2 weeks. We're promoting frequent pushes to
> story branches.
> 
> After a number of experiments and doing online research, we're
> thinking to use rebase to keep the story branches up-to-date with
> master while the story branches are in development. This seems to be
> the best approach because it will allow us to use bisect to isolate
> issues, and it will give us the most linear history graph. 

In my experience rebasing branches does only work seamlessly when one
developer (or one machine for a pair programming setup) is working on
the branch being rebased. Having a one branch per story for multiple
developers which will be frequently rebased sounds like it will
introduce a lot of branch management work.

IMO, even though branching and merging is cheap in git the goal to merge
as early as possible still applies. Having long lived seperate branches
has the potential to introduce a lot of conflicts.

If you are doing scrum you probably will divide the user story into
tasks. I would suggest to do short task branches which can be reviewed
and merged into one main branch (probably master) after one or two days.
That way you minimize the risk of a big integration hell when all teams
want to merge their changes after their story is done.

Just my ideas how things can work best.

Cheers Heiko