CODEWITHSUNDEEP
gitgit-flow
Fred2020
Fred2020

Reputation: 487

Gitflow, managing hotfixes, version tags and releases

I'm following the GitFlow workflow but I'd like to know how people approach the issue of bugs with versioning/releases

We have a set of features that are linked to versions.

feature set {A,B,C} --> v1.0.1

feature set {D,E,F} --> v1.0.2

Each time a feature set is completed we add a tag with the version number to develop branch. This allows development to continue at it's own speed and we can then selectively choose a version, based on the version tag, to cut to our release branch which can end up in SIT, PREPROD etc

Imagine a scenario where the develop branch has a latest version tag of v1.0.10 and Production environment is running v1.0.5. If a bug is noticed in Production

Later on if I wanted to move Production to the next version v1.0.6 and have that hotfix included, how would I do so? Isn't that hotfix only available now post tag v1.0.10 in develop?

Upvotes: 3

Views: 3051

Answers (1)

TTT
TTT

Reputation: 28944

Standard Git Flow doesn't really handle your specific workflow as you described. Fortunately I believe with a minor workflow tweak you can resolve it.

The standard Git Flow assumes everything on the develop branch is going to land in Production (and consequently master or in your case main), in the next release (or the one after if a release is already pending). In the case when a release branch exists, and a hotfix goes into main, you also merge that hotfix (or main) back into the release branch right away. In your question's scenario, when a release branch doesn't exist yet, you would merge it back into develop, and this is where your problem arises because you don't intend to release the tip of develop yet, which is where you're deviating from standard Git Flow.

To solve this, I would propose one of these options:

  1. As soon as you know which commit on develop will represent your next release, create a release branch for it. Then if a hotfix hits main you can merge main back into the release branch instead of develop, guaranteeing you won't overwrite the hotfix changes in production. Note this might correspond nicely with your PREPROD branch, in which case you should make sure it always exists at the time you need to merge hotfixes into main back down into it. At that time you might have to also merge PREPROD right back down to develop. From there, you simply need to make sure that the next time you make PREPROD it comes after that new merge in develop. If your release cycle is so delayed that even that isn't possible, then that leads us to the next option:
  2. You could add a sub-workflow to your existing Git Flow. This is exactly what we do at my organization. The basic concept is that you have another throwaway integration branch, which I recommend calling next, which is where feature branches go to get hardened. Once they are proven and ready, you re-merge those commits into develop which means they will be included in the next release branch. Although this adds more complexity, you gain the ability to work out bugs earlier and only merge well-tested code into develop. Furthermore, it also enables you to release features out of order if you wish to, because you get to decide which features to merge into develop. Since you seem to have a long cycle for hardening your feature branches before they get deployed, this may work well for you. If you go this route I would recommend not tagging those features on the next branch, since the next branch should be reset to develop periodically. You may not need to tag those features at all anymore, and could instead tag the releases containing multiple features, as you deploy them. By the way, this sub-workflow is called gitworkflows and is what the maintainers of Git use, but without Git Flow also tacked on to it.

Side Note: You may have noticed I mentioned merging main back into release or develop instead of merging the release or hotfix branches themselves back down as standard Git Flow describes. This is functionally equivalent to the standard Git Flow suggestion, but I prefer this simply so the extra merge commit on main gets brought back down too. This way extra merge commits don't collect on main over time and get brought down all at once with a hotfix. It also keeps develop fully up to date with main so you don't see any commit IDs on main that aren't present in develop.

Upvotes: 2

Related Questions