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

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