2

This is related to trying to deal with unfinished user stories. An example:

In sprint 1, there is a user story #100. So we create a sprint branch (sprint-1) and then off that branch a user story branch (us-100). At the end of the sprint, the user story is not completed. The normal process is that user stories use pull requests to merge into the sprint branch and after the review, the sprint branch is merged into develop (using a pull request). Then the sprint branch is deleted. Since us-100 was not completed, it wasn't merged into sprint-1 and when sprint-1 is deleted, I'm not sure what is going on with us-100.

What I'd like to do is to "move" the us-100 branch to another sprint, e.g. to sprint-2 branch. Is this possible? How? Or is there a better way?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Greg McGuffey
  • 3,116
  • 3
  • 38
  • 58
  • 1
    What is the value of discrete sprint branches vs a develop/master branching model? – Oliver Charlesworth Dec 10 '15 at 20:11
  • 1
    I really don't think that you should try to reflect your sprints in branches. If you somehow want to mix it, then I would create a branch for each story and sub branches for single features of that story (if needed). – Core_F Dec 10 '15 at 20:45

2 Answers2

2

Just rebase your branch onto the new shared sprint branch.

For example:

git checkout us-100
git fetch
git rebase origin/sprint-2
git push -f origin us-100

Note that using -f (--force) is re-writing the history of the sprint-2 branch. IMO this is the correct thing to do, but if there are others who are also using that branch they will need to adjust since their version of sprint-2 will now be different.

They can do:

git checkout us-100
git fetch
git rebase origin/us-100

Now, the sprint-2 branch will be based off of your new sprint branch and you can proceed with it as usual.

Jonathan.Brink
  • 23,757
  • 20
  • 73
  • 115
1

Your approach is delaying code merges and quite possibly hiding issues until the last minute.

For example, say you do a review and decide to proceed with a code merge. There could then potentially be merge problems that may even result in some refactoring being necessary. Also, this would be the first time you would be running regression tests on the merged codebase.

There is a real risk of giving a false impression of progress, by showing 'finished' stories that are in fact still work in progress.

At the very least I would recommend with this approach you do regular merges from head in to each code branch. That way you will spot potential merge conflicts as you go along. That does not mitigate the regression testing risk though. You could perhaps have a continuous integration build job for each branch that does a nightly merge with head and runs automated regression tests against it.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
  • In general we don't merge until the coding is finished, unit tested and code reviewed. In the scenario I'm asking about, there would have been a problem (the story was too large, ran into an issue, team members out...whatever) and the coding wasn't finished. In other terms, merging the user story early would just put the rest of the code base at risk because we know the code from the user story isn't stable yet. Ideally, this scenario never happens, but I'm on a new team and they are often biting off more than they can chew... – Greg McGuffey Dec 15 '15 at 23:39
  • I think you may have misunderstood my answer. I was suggesting you merge from your head in to your branches (head -> branch), not the other way around. That way you can have confidence your branches are still compatible with the head, even if changes have taken place. Plus, when you come to merge the branch back in to head (branch -> head) it should be a trivial matter. There is no added risk with this approach as the code does not get merged in to head until you are ready. – Barnaby Golden Dec 16 '15 at 07:38
  • Ah, I see what you are saying. Thanks! That will be helpful as well. – Greg McGuffey Dec 22 '15 at 19:22