Menu
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.
346
Delete local Git branch commandgit branch –delete old-branch. git branch -d old-branch.
Gitflow release branch process overview The release branch represents a complete feature set. The only commits on the release branch are for bug fixes and important chores. The Gitflow release branch is created off the development branch. Gitflow release is merged into master and also back into development.
Build your strategy from these three concepts: Use feature branches for all new features and bug fixes. Merge feature branches into the main branch using pull requests. Keep a high quality, up-to-date main branch.
First, you need to make sure your local main is synchronized with the upstream main . Then, you merge the feature branch into main and push the updated main back to the central repository. Pull requests can be facilitated by product repository management solutions like Bitbucket Cloud or Bitbucket Server.
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.
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.
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.
162
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
