When learning Git for the first time, I posted Git branching and tagging best practices. I learned a lot from this and have adapted git flow patterns to my personal projects since then. I am now in charge of a project at my job where I am trying to apply these concepts with a team for the first time.

We have been merging feature branches into devel and when we are ready to make a release, I create a release branch from devel which can be staged on a cloud server for the customer to review before pushing to production. While the customer is reviewing the release candidate, we continue developing additional features for the next release.

We have encountered a situation where the customer is requesting significant changes to our currently planned release (let's call this release-a). We also have several features that we have developed that are ready for review by a senior engineer (call these feature1 and feature2) and we want to release without waiting for the requested changes that are planned for release-a. The problem is that all of the features on release-a have already been merged into devel then feature1 and feature2 were created from devel. So the git repo looks something like this:

X <- master (tagged as version 1.3)
 \- A ... B <- devel (contains features planned for release-a but shouldn't be in release-b)
          | \
          |  C ... D <- release-a (bug fixes here)
          |- E ... F <- feature1 (and similarly for feature2)

What are some common ways to handle a situation like this? I need to prepare feature1 and feature2 for release without including any of the features that were originally planned for release-a. I have rebased the two feature branches with git rebase --onto master devel. But then what? Should I just create a new release-b branch to merge these into master when its time to push to production and into devel to include the features in continued development?

  • Are the changes the customer requests on release-a simply bug fixes or new development? Are they changes you (eventually) want to include in other releases?
    – mmathis
    Commented Apr 22, 2019 at 16:42
  • @mmathis I modified my picture to be more clear. release-a is the release branch that I created from devel (following git flow recommendations) to prepare for releasing the new features in commits A...B. Commits C...D contain the bug fixes that will also be included in that release and eventually merged into master. Note that feature1 also contains A...B, but now those should no longer be released. Instead, I need to prepare E...F as its own release without A...B. I understand I can rebase these commits onto master, but this doesn't seem to follow git flow patterns.
    – Code-Guru
    Commented Apr 22, 2019 at 20:49
  • @mmathis The fundamental problem here is that we have been developing features and merging them into devel to prepare for a release. The requested fixes on release-a are modifications to the features that we are releasing. I guess they qualify more as bug fixes because what we have isn't quite what the customer wants. Then management decided not to release those features yet but to release another set of features instead as the next release..
    – Code-Guru
    Commented Apr 22, 2019 at 21:03

1 Answer 1


It sound like you need to create a hotfix branch that you can release to master, which you could incorporate feature1 and feature 2 into. Then you could have those changes pushed into the release when it is ready to be released. Here is a good resource on successful Git branching that describes in a little more detail of the above thoughts:


  • That's more or less what I ended up doing. I rebased feature 1 and feature 2 directly onto master so that they no longer had any of the features that were already merged into devel. However, this seems very hacky to me because these aren't really "hot fixes". Rather it is a kink in planning for feature releases that I am trying to work around.
    – Code-Guru
    Commented Apr 22, 2019 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.