0

We have three main branches. develop, uat and master. We are in the last week of current sprint. It has been decided to postpone one feature to the next release. That feature is already in uat environment. So team wants to keep it in uat branch. So before merging into master, I have to remove that feature which has 3 commits.

I can create a release branch from uat, revert those 3 commits and merge into master. But next time conflict might occur in master branch since usual merge UAT into master. In addition to that, release branch is a temporary branch that will be created for this scenario and it will be deleted after merge.

I don't want to mess up with master branch. Please suggest if there is any better way to handle this scenario.

Ela
  • 419
  • 1
  • 6
  • 20
  • 1
    With a release branch from uat you can fix any merge conflicts on that release branch before merging it to master again. I think your first thought seems reasonable. – Martin G Oct 25 '17 at 13:46
  • Thanks @Martin the problem is release branch is a temporary branch that will be created for this scenario. It will be gone after current release is completed. We always merge from UAT into master. – Ela Oct 25 '17 at 13:56
  • 1
    @Ela: that's key information that probably should have been in your original question (you could edit it in now). Note that if you delete the branch name, the commits it retains could be garbage-collected—that seems contrary to the point of a release. – torek Oct 25 '17 at 14:05
  • Thanks @torek Actually we don't have the release branch in our branching strategy. That is a temporary branch and it is like creating a bugfix branch when needed. – Ela Oct 25 '17 at 14:12
  • 1
    @torek If the branch is merged, you can safely delete the branch name (no history is lost). It is only when the branch is not merged anywhere that those commits would be potentially discarded. [Why Delete Old Git Branches?](https://ardalis.com/why-delete-old-git-branches) – crashmstr Oct 25 '17 at 14:15
  • Another question. Can we skip some features while deploying to production in Continuous delivery process? I believe Production like environment (UAT, staging) is must in CD. – Ela Oct 25 '17 at 14:34
  • @crashmstr: As long as it's a real merge (not a squash "merge"), sure. I find that it helps a lot to draw the intended graph, remembering that branch and tag names like "v1.1" point to specific commits (with branch names automatically extending to encompass new commits). It then becomes obvious (or at least not too opaque) what future commits and merges will do. – torek Oct 25 '17 at 15:29
  • I think the simplest practice for this might be to use interactive rebase or equivalently some cherry-picks to sequence the production-ready changes before the not-yet-ready ones, and merge the production-ready ones, leaving the still-pending work right where you want it. – jthill Oct 26 '17 at 03:45
  • @Ela Have you delete the commits successfully? – Marina Liu Nov 06 '17 at 03:20
  • @Marina-MSFT yes..We have deleted the commits. 2nd scenario helped in our case. Thanks! – Ela Nov 07 '17 at 09:43

1 Answers1

1

The workflow you are using seems: continuous build/deploying for uat branch, and then merge uat branch into master for a new release.

So I will suggest backup current uat branch, remove the three commits on uat branch. After merging uat branch into master, recovery/reapply the three commits on uat branch again for next release.

There have two situations for you to change and recovery/reapply uat branch. You can follow one the below situations you meet.

Situation 1: the three commits are the latest three commits on uat branch

Assume the commit history looks as below, and the commit D, E and F are the commits for the feature that you decide to postpone for next release.

…---A---B            master
…---C---D---E---F   uat

You can use below commands to backup current uat branch and then remove the three commits on uat branch:

git checkout -b temp uat
git checkout uat
git reset --hard HEAD~3

Then the commit history looks like:

…---A---B         master
…---C             uat
     \
      D---E---F   temp

And now, you can merge uat into master for the new release, so the commit history will be:

…---A---B---G           master
           /
…---------C             uat
           \
            D---E---F   temp

Then you can recovery uat branch as original by

git checkout uat
git merge temp
git branch -D temp

Then the commit history looks as below, and the three commits D, E and F will apply for next release when merge uat into master for next time.

…---A---B---G             master
           /
…---------C---D---E---F   uat

Situation 2: the three commits are not the latest commits, there has other commit(s) after the three commits

Assume the commit history as below, and the commits D, E and F are the commits you want to remove. And there have commits G and H after the three commits.

…---A---B    master
…---C---D---E---F---G---H   uat

To backup current uat and remove the three commits on uat branch, you can use below commands:

git checkout -b temp uat
git checkout uat
git rebase --onto uat~5 uat~2 uat

The commit history will be:

…---A---B         master
…---C---G'---H'   uat
         \
          D---E---F---G---H   temp

After merge uat into master, the commit history looks like:

…---A---B------I   master
              /
…---C---G'---H'   uat
     \
      D---E---F---G---H   temp

Then you can re-apply the three commits D, E and F on uat branch by below commands:

git checkout temp
git reset --hard HEAD~2
git rebase uat temp
git checkout uat
git merge temp
git branch -D temp

Then the commit history will be:

…---A---B------I    master
              /
…---C---G'---H'---D'---E'---F'   uat

And the three commits D', E' and F' can be release for next time.

Marina Liu
  • 36,876
  • 5
  • 61
  • 74