2 added 20 characters in body
source | link

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:

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

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:

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?

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?

1
source | link

Managing release branches in Git

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:

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?