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

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

[Christofer Jennings]

Hi All,

(New to this list. Please tell me if this is the wrong forum for this thread.) 

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. 

So, here's my question: Can we use "rebase -s recursive -Xtheirs" as shown below?

In this experiment, we're on 'story' branch 's1'. It's behind master because another story has been merged to master. We need to rebase to master and then rebase to origin/s1to be up-to-date. So we...
git fetch -v
git rebase origin/master
... resolve stuff ...
git rebase -s recursive -Xtheirs origin/s1
The "-s recursive -Xtheirs" part seems to result in all the right code at the end. We only had to "git add && git rebase --continue" for deleted files.

Would this approach always work? Or do we actually need to step through each conflict while rebasing to origin/s1 too?

(I don't want to step through each conflict while rebasing to origin/s1 because it brings up conflicts that the s1 developer may know nothing about.)

Thanks!
chris

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

[Michael Witten]

On Sat, 9 Jun 2012 16:51:28 -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.

You can use bisect to isolate issues regardless of merges. Also, linear
histories are not always better histories; for one, merge commits can
usefully encode the way that something was actually developed.

> So, here's my question: Can we use "rebase -s recursive -Xtheirs" as
> shown below?
>
> In this experiment, we're on 'story' branch 's1'. It's behind master
> because another story has been merged to master. We need to rebase
> to master and then rebase to origin/s1 to be up-to-date. So we...
>
>   git fetch -v
>   git rebase origin/master
>   ... resolve stuff ...
>   git rebase -s recursive -Xtheirs origin/s1

Let's expand that a bit for the sake of discussion:

  git fetch -v
  git branch -f s1_0            # Additional line
  git rebase origin/master
  ... resolve stuff ...
  git branch -f s1_1            # Additional line
  git rebase -s recursive -Xtheirs origin/s1

So:

  * The first rebase applies all the commits in `origin/master..s1_0'
    on top of the commit to which `origin/master' points; the branch
    heads `s1' and `s1_1' are then set to point to the youngest of
    the resulting commits.

  * The second rebase applies all the commits in `origin/s1..s1_1'
    on top of the commit to which `origin/s1' points; the branch
    heads `s1' and `s1_2' are then set to point to the youngest of
    the resulting commits.

In that second rebase, the range:

  origin/s1..s1_1

is equivalent to:

  ^origin/s1 s1_1

which is equivalent to:

  ^origin/s1 origin/master s1_1

because `origin/master' is reachable from `s1_1'. This in turn is
equivalent to:

  origin/s1..origin/master origin/s1..s1_1

In other words, the second rebase applies all the commits in
`origin/s1..origin/master' (namely, possibly the commits from
the other story) ON TOP of the commit pointed to by `origin/s1',
which is probably not what you want; the code might be correct,
but the history is probably not.

To see for yourself, try this small example:

  $ git init origin; cd origin
  $ echo 0 > a; git add a; git commit -m Initial
  $ git branch s1
  $ echo 1 > a; git commit -am 'Other Story'
  $ cd ..; git clone origin local
  $ cd origin; git checkout s1
  $ echo 0 > b; git add b; git commit -m 'Shared s1 update'
  $ cd ../local
  $ git checkout -b s1 origin/s1
  $ echo 0 > c; git add c; git commit -m 'Local s1 work'
  $ git fetch
  $ git rebase origin/master
  $ git rebase origin/s1
  First, rewinding head to replay your work on top of it...
  Applying: Other Story
  Applying: Local s1 work
  $ git log --format=%s --graph
  * Local s1 work
  * Other Story
  * Shared s1 update
  * Initial

> The "-s recursive -Xtheirs" part seems to result in all the right code
> at the end. We only had to "git add && git rebase --continue" for
> deleted files.

Two points:

  * I think it's dangerous to ignore any conflicts, let alone when mixing
    code from multiple upstreams.

  * Be certain that you don't want -Xours. IIRC, during a rebase, the commits
    that have already been placed in the new history (which includes the
    upstream) are considered `ours' during a rebase.

Basically, you need to define more strictly what "upstream" means in your
project, and you need to be less afraid of merging, a fundamental process
around which git was designed.

Sincerely,
Michael Witten

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

[Heiko Voigt]

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

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

[Christofer Jennings]

Thanks Heiko and Michael! Your emails were very helpful.

We did some experiments similar to yours, Michael, and came to the conclusion that we'll use merge to synchronize between branches that have been shared remotely (e.g., origin/master and origin/s1). Rebase fits our needs for synchronizing local working branches their corresponding origin branches though (e.g., s1 and origin/s1). In those cases, merge causes too many splits in the log.

This is all working out pretty well to support our "Story branch" approach.

Thanks again,
,chris

On Jun 9, 2012, at 4:51 PM, Christofer Jennings wrote:

> Hi All,
> 
> (New to this list. Please tell me if this is the wrong forum for this thread.) 
> 
> 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. 
> 
> So, here's my question: Can we use "rebase -s recursive -Xtheirs" as shown below?
> 
> In this experiment, we're on 'story' branch 's1'. It's behind master because another story has been merged to master. We need to rebase to master and then rebase to origin/s1to be up-to-date. So we...
> git fetch -v
> git rebase origin/master
> ... resolve stuff ...
> git rebase -s recursive -Xtheirs origin/s1
> The "-s recursive -Xtheirs" part seems to result in all the right code at the end. We only had to "git add && git rebase --continue" for deleted files.
> 
> Would this approach always work? Or do we actually need to step through each conflict while rebasing to origin/s1 too?
> 
> (I don't want to step through each conflict while rebasing to origin/s1 because it brings up conflicts that the s1 developer may know nothing about.)
> 
> Thanks!
> chris