{"thread":{"id":"30755","subject":"Sanity Check: scrum teams, shared 'story branches', rebasing shared branches","startedAt":"2012-06-09T23:51:28Z","lastAt":"2012-06-14T14:32:22Z","messageCount":4,"participants":["Christofer Jennings","Michael Witten","Heiko Voigt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"193223","messageId":"3EA7D039-9D6E-4945-A982-43DB53AAE43A@gmail.com","threadId":"30755","inReplyTo":null,"subject":"Sanity Check: scrum teams, shared 'story branches', rebasing shared branches","fromName":"Christofer Jennings","fromEmail":"boz.lists@gmail.com","sentAt":"2012-06-09T23:51:28Z","receivedAt":"2012-06-09T23:51:28Z","isPatch":false,"sender":{"key":"boz.lists@gmail.com","avatar":null},"body":"Hi All,\n\n(New to this list. Please tell me if this is the wrong forum for this thread.) \n\nI'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.\n\nAfter 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. \n\nSo, here's my question: Can we use \"rebase -s recursive -Xtheirs\" as shown below?\n\nIn 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...\ngit fetch -v\ngit rebase origin/master\n... resolve stuff ...\ngit rebase -s recursive -Xtheirs origin/s1\nThe \"-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.\n\nWould this approach always work? Or do we actually need to step through each conflict while rebasing to origin/s1 too?\n\n(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.)\n\nThanks!\nchris"},{"id":"193224","messageId":"f02de4149bf84cd78e41c22088413b31-mfwitten@gmail.com","threadId":"30755","inReplyTo":"3EA7D039-9D6E-4945-A982-43DB53AAE43A@gmail.com","subject":"Re: Sanity Check: scrum teams, shared 'story branches', rebasing shared branches","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2012-06-09T23:51:28Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sat, 9 Jun 2012 16:51:28 -0700, Christofer Jennings wrote:\n\n> I've been using Git and GitHub for ~6 months. Working on a SCM plan\n> for a Scrum project with 50+ developers in ~8 dev. teams. Each team\n> will be working on one or two stories simultaneously, so expect ~16\n> 'story branches' (and master) at any given time. We've got GitHub\n> Enterprise and are working out how to manage story development on\n> shared branches that get merged to master only after going through\n> acceptance & peer review. We hope stories will only be 3 - 5 days to\n> complete, but may take 2 weeks. We're promoting frequent pushes to\n> story branches.\n>\n> After a number of experiments and doing online research, we're\n> thinking to use rebase to keep the story branches up-to-date with\n> master while the story branches are in development. This seems to be\n> the best approach because it will allow us to use bisect to isolate\n> issues, and it will give us the most linear history graph.\n\nYou can use bisect to isolate issues regardless of merges. Also, linear\nhistories are not always better histories; for one, merge commits can\nusefully encode the way that something was actually developed.\n\n> So, here's my question: Can we use \"rebase -s recursive -Xtheirs\" as\n> shown below?\n>\n> In this experiment, we're on 'story' branch 's1'. It's behind master\n> because another story has been merged to master. We need to rebase\n> to master and then rebase to origin/s1 to be up-to-date. So we...\n>\n>   git fetch -v\n>   git rebase origin/master\n>   ... resolve stuff ...\n>   git rebase -s recursive -Xtheirs origin/s1\n\nLet's expand that a bit for the sake of discussion:\n\n  git fetch -v\n  git branch -f s1_0            # Additional line\n  git rebase origin/master\n  ... resolve stuff ...\n  git branch -f s1_1            # Additional line\n  git rebase -s recursive -Xtheirs origin/s1\n\nSo:\n\n  * The first rebase applies all the commits in `origin/master..s1_0'\n    on top of the commit to which `origin/master' points; the branch\n    heads `s1' and `s1_1' are then set to point to the youngest of\n    the resulting commits.\n\n  * The second rebase applies all the commits in `origin/s1..s1_1'\n    on top of the commit to which `origin/s1' points; the branch\n    heads `s1' and `s1_2' are then set to point to the youngest of\n    the resulting commits.\n\nIn that second rebase, the range:\n\n  origin/s1..s1_1\n\nis equivalent to:\n\n  ^origin/s1 s1_1\n\nwhich is equivalent to:\n\n  ^origin/s1 origin/master s1_1\n\nbecause `origin/master' is reachable from `s1_1'. This in turn is\nequivalent to:\n\n  origin/s1..origin/master origin/s1..s1_1\n\nIn other words, the second rebase applies all the commits in\n`origin/s1..origin/master' (namely, possibly the commits from\nthe other story) ON TOP of the commit pointed to by `origin/s1',\nwhich is probably not what you want; the code might be correct,\nbut the history is probably not.\n\nTo see for yourself, try this small example:\n\n  $ git init origin; cd origin\n  $ echo 0 > a; git add a; git commit -m Initial\n  $ git branch s1\n  $ echo 1 > a; git commit -am 'Other Story'\n  $ cd ..; git clone origin local\n  $ cd origin; git checkout s1\n  $ echo 0 > b; git add b; git commit -m 'Shared s1 update'\n  $ cd ../local\n  $ git checkout -b s1 origin/s1\n  $ echo 0 > c; git add c; git commit -m 'Local s1 work'\n  $ git fetch\n  $ git rebase origin/master\n  $ git rebase origin/s1\n  First, rewinding head to replay your work on top of it...\n  Applying: Other Story\n  Applying: Local s1 work\n  $ git log --format=%s --graph\n  * Local s1 work\n  * Other Story\n  * Shared s1 update\n  * Initial\n\n> The \"-s recursive -Xtheirs\" part seems to result in all the right code\n> at the end. We only had to \"git add && git rebase --continue\" for\n> deleted files.\n\nTwo points:\n\n  * I think it's dangerous to ignore any conflicts, let alone when mixing\n    code from multiple upstreams.\n\n  * Be certain that you don't want -Xours. IIRC, during a rebase, the commits\n    that have already been placed in the new history (which includes the\n    upstream) are considered `ours' during a rebase.\n\nBasically, you need to define more strictly what \"upstream\" means in your\nproject, and you need to be less afraid of merging, a fundamental process\naround which git was designed.\n\nSincerely,\nMichael Witten\n"},{"id":"193266","messageId":"20120610154810.GA2427@book.hvoigt.net","threadId":"30755","inReplyTo":"3EA7D039-9D6E-4945-A982-43DB53AAE43A@gmail.com","subject":"Re: Sanity Check: scrum teams, shared 'story branches', rebasing shared branches","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-06-10T15:48:12Z","receivedAt":"2012-06-10T15:48:12Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Sat, Jun 09, 2012 at 04:51:28PM -0700, Christofer Jennings wrote:\n> I've been using Git and GitHub for ~6 months. Working on a SCM plan\n> for a Scrum project with 50+ developers in ~8 dev. teams. Each team\n> will be working on one or two stories simultaneously, so expect ~16\n> 'story branches' (and master) at any given time. We've got GitHub\n> Enterprise and are working out how to manage story development on\n> shared branches that get merged to master only after going through\n> acceptance & peer review. We hope stories will only be 3 - 5 days to\n> complete, but may take 2 weeks. We're promoting frequent pushes to\n> story branches.\n> \n> After a number of experiments and doing online research, we're\n> thinking to use rebase to keep the story branches up-to-date with\n> master while the story branches are in development. This seems to be\n> the best approach because it will allow us to use bisect to isolate\n> issues, and it will give us the most linear history graph. \n\nIn my experience rebasing branches does only work seamlessly when one\ndeveloper (or one machine for a pair programming setup) is working on\nthe branch being rebased. Having a one branch per story for multiple\ndevelopers which will be frequently rebased sounds like it will\nintroduce a lot of branch management work.\n\nIMO, even though branching and merging is cheap in git the goal to merge\nas early as possible still applies. Having long lived seperate branches\nhas the potential to introduce a lot of conflicts.\n\nIf you are doing scrum you probably will divide the user story into\ntasks. I would suggest to do short task branches which can be reviewed\nand merged into one main branch (probably master) after one or two days.\nThat way you minimize the risk of a big integration hell when all teams\nwant to merge their changes after their story is done.\n\nJust my ideas how things can work best.\n\nCheers Heiko\n"},{"id":"193654","messageId":"4E5D3B5D-DFAA-4FA7-ABA7-872584951221@gmail.com","threadId":"30755","inReplyTo":"3EA7D039-9D6E-4945-A982-43DB53AAE43A@gmail.com","subject":"Re: Sanity Check: scrum teams, shared 'story branches', rebasing shared branches","fromName":"Christofer Jennings","fromEmail":"boz.lists@gmail.com","sentAt":"2012-06-14T14:32:22Z","receivedAt":"2012-06-14T14:32:22Z","isPatch":false,"sender":{"key":"boz.lists@gmail.com","avatar":null},"body":"Thanks Heiko and Michael! Your emails were very helpful.\n\nWe 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.\n\nThis is all working out pretty well to support our \"Story branch\" approach.\n\nThanks again,\n,chris\n\nOn Jun 9, 2012, at 4:51 PM, Christofer Jennings wrote:\n\n> Hi All,\n> \n> (New to this list. Please tell me if this is the wrong forum for this thread.) \n> \n> 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.\n> \n> 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. \n> \n> So, here's my question: Can we use \"rebase -s recursive -Xtheirs\" as shown below?\n> \n> 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...\n> git fetch -v\n> git rebase origin/master\n> ... resolve stuff ...\n> git rebase -s recursive -Xtheirs origin/s1\n> 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.\n> \n> Would this approach always work? Or do we actually need to step through each conflict while rebasing to origin/s1 too?\n> \n> (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.)\n> \n> Thanks!\n> chris\n"}]}