Using Git to merge all changes from a feature branch on develop to a release branch

Question

We use GitFlow to manage our software repositories: http://nvie.com/posts/a-successful-git-branching-model/

I have a situation that I'm not sure how to handle in this branching model.

I made about a dozen commits to a feature branch (branched off develop ) over the course of a couple weeks. To reduce the burden of merging back to develop , I merged changes from develop into my feature branch 3 times over the course of those 2 weeks. The feature branch was completed and its changes are merged back into develop .

However, as it turns out, this feature is also required on a release branch that was branched off from develop about a month ago. Is there a way to merge just the changes from that old branch, but omit the changes to develop that I merged into it 3 times?

Answer 1

According to the Git Flow model, you missed the train

Your repo must look something like that:

o - o - o - o - o - o [master]
 \
  \       o - o - o - o - o [release]
   \     / 
    o - o - o - o - o - o - o - o - o - o - o [develop]
                 \       \       \         /
                  o - o - o - o - o - o - o [feature]

However, if you and your team are indeed following the Git Flow model, I've got bad news for you: the ship has sailed. More specifically, it's too late for you to incorporate the features from your feature branch (now also in develop ) into the release branch. That's just not allowed by Git Flow.

If you look at the following part of the main nvie.com graph, you'll see that, once a release branch is created, it's not allowed to receive anything from develop , let alone any feature branch. The only purpose of a release branch is stabilisation/consolidation towards the actual release, ie a merge into master .

If you really stick to the Git Flow model, you should

• either abandon the current release branch and create a new one stemming from the tip of develop ,
• or freeze all work on release and then rebase it onto develop before resuming work on it,
• or wait for the next release to incorporate your new features into a release.

If you're fine with not sticking to Git Flow...

If you're willing to go against Git Flow on this one, you can always get your features into release without polluting it from recent things from develop . The downside of the following approach is that your history will be a bit messy and will contain "duplicate commits"; but I don't think you have much of a choice if you really insist on incorporating your features from the feature branch into your current/active release.

For convenience, let's assume your repo looks as follows (I've labelled a few commits with letters):

o - o - o - o - o - o [master]
 \
  \       o - o - o - o - o [release]
   \     / 
    o - A - B - C - o - o - o - o - o - o - o [develop]
                 \       \       \         /
                  D - E - F - G - H - I - J [feature]

What you could do is

1. Check out release

    git checkout release 

2. Get a list of all the revisions that were not merge commits, between commit A and the tip of feature ; in this case, that would be commits B, C, D, E, G, I and J. The command

    git rev-list --no-merges A..feature 

   should do that for you.

3. Pass that list of revisions to cherry-pick in order to apply the changes introduced by those commits on top of release :

    git cherry-pick `git rev-list --no-merges A..feature` 

   You'll end up with something like this:

    o - o - o - o - o - o [master] \\ \\ o - o - o - o - o - B'- C'- D'- E'- G'- I'- J' [HEAD=release] \\ / \\ / o - A - B - C - o - o - o - o - o - o - o [develop] \\ \\ \\ / D - E - F - G - H - I - J [feature] 

4. Stabilise the release branch.

5. Once release hits master , you should also merge it into develop , and you should be back on your feet.