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
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
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
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?