Git flow - managing differences between master and develop

Question

I've been using Git Flow for a little while now, however in the initial week or so I was creating release branches manually from master and cherry picking the required commits into the release branch rather than creating them from master.

For example, if I have commit abcd123 My commit message in the develop branch, I had also cherry picked it into the release branch manually, and at this point I had probably amended or edited the commit message, so the release branch (and now master branch) contain this commit but with a different hash, e.g. dbca321 My adjusted commit message.

The problem here is that when I create the release from develop, it also contains commits that I don't want to deploy at this stage, so I rebase against master and exclude the commits I don't want. After rebasing however, the commit hash is different for "My commit message" above between master, the release and develop. This probably explains why it keeps showing up whenever I create a release.

I want to be able to use Git Flow to create releases from develop, but remove certain commits where necessary without having this issue occur. Creating the release branches manually via cherry picking is an easy way to achieve that, and when it is back merged to develop it seems to work nicely, however it's not how Git Flow is supposed to be used.

How do I get Git Flow (master/develop) back on track/in sync and achieve this?

Answer 1

I've been using gitflow for a while. Here's my practice for it:

1. Everything goes into develop until you feel you are ready to start preparing the release. This may be any timeframe between minutes and days from the last deployment.
2. Create a release branch off of develop, or better yet - off of the last commit on the develop branch that should really go into the release. The idea is to minimise the cherry-picks or reverts between develop and release, as they cause headaches.
3. Keep committing into release, unless you are adding/changing something that cannot go into the release branch. In this case, commit to develop, but again try to minimise to reduce the merge headache.
4. When ready, merge the release branch into develop and master, test and deploy.
5. Go back to 1.

Some GUI tools wrap git nicely and offer one-click gitflow actions, but you should always strive to know what happens under the hood to troubleshoot these 'automatic' tools when they fail.