CODEWITHSUNDEEP
gitbranchreleasegit-flow
Rober
Rober

Reputation: 726

Git flow - get rid of a particular feature

I'm currently trying to set up a development process in my team and read about GitFlow. It looks interesting, but I can spot a few issues.

Let's assume the following scenario:

We finish features F1, F2 and F3, and merge these into the develop branch. Based on this we create a release branch.

What could we do if we want to get rid of feature F3?

Take a look at this image to get a better idea.

enter image description here

Upvotes: 6

Views: 3433

Answers (1)

Alex Wolf
Alex Wolf

Reputation: 20118

This is indeed a weakness of git-flow. As I see it there exist multiple ways to approach this problem, of which none is perfect.

Feature revert

One way would be to simply revert the merge commit from F3.

git checkout <release-branch>
git revert --mainline 1 <hash-of-f3-merge-commit>

--mainline 1 (short -m 1) tells git to revert the changes of the merge commit relative to it's first parent, which is the branch in which the changes were merged in. In our case this would be develop.

On the other hand this will lead to problems when you merge the release branch back into develop, since that will also merge the revert. You will probably have to re-merge the feature (F3) into develop.

Alternative release base

This approach bases your release branch on the latest state of master instead of develop.

git checkout -b master <release-branch>

From here on you can cherry-pick each feature you want to include in the release. Again using the --mainline option.

git cherry-pick --mainline 1 <hash-of-f1-merge-commit>
git cherry-pick --mainline 1 <hash-of-f2-merge-commit>

Alternativly you can merge the feature branches into the release branch instead of cherry-picking them, which will result in the same outcome but in a more cluttered history (this can be avoided using the --squash option followed by a git commit, but then you have effectively done a cherry-pick).

git merge F1
git merge F2

The alternative release base approach isn't so bad if each release only contains a small subset of the developed features, but is hard to use if you want to release a large number of features.

Personally I prefer the latter approach since it results in a cleaner history without reverts and duplicated merge commits.

Upvotes: 8

Related Questions