git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Heiko Voigt <hvoigt@hvoigt.net>
Date
Jun 10, 2012, 15:48 UTC
Message-ID
<20120610154810.GA2427@book.hvoigt.net>
In-Reply-To
<3EA7D039-9D6E-4945-A982-43DB53AAE43A@gmail.com>
Hi,
On Sat, Jun 09, 2012 at 04:51:28PM -0700, Christofer Jennings wrote:
Show 15 quoted lines
> 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
Previous: Michael WittenNext: Christofer Jennings
Message 3 of 4 in “Sanity Check: scrum teams, shared 'story branches', rebasing shared branches”
  1. Christofer JenningsJun 9, 2012
  2. Michael WittenJun 9, 2012
  3. Heiko VoigtJun 10, 2012
  4. Christofer JenningsJun 14, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.