What is correct way to work with hotfix branch in GitLab flow?

user_1986386 0
Viewed 141

I use GitLab flow environment branches in GitHub service. I have 3 secured from direct commits branches main (dev branch), staging (pre-prod) and production branches. I deployed release-1 to production. After that I merge significant code refactoring to main branch. In prod I found an issue in module which I refactored in main branch and need to fix it in prod. I couldn't find such scenario in GitLab flow examples. So what can I do:

  1. Check out hot-fix-1 branch from production.
  2. Make a fix in hot-fix-1 branch.
  3. Merge this fix to staging to test.
  4. If everything OK, I merge from staging to production.

Because module is refactored in main branch fix should be done in a different way in main. So I create new branch from main, fix the issue and merge back to main. Is this correct?

Now I added Feature2 to main branch and want to release it. When I create PR from main to staging I will get a conflict. To resolve this conflict I need to merge staging to main and resolve the conflict. But this contradicts with GitLab flow.

How would you do hot fix in production in case of significant code change in problem module in dev branch? enter image description here

gitlab git
1 Answers

To resolve this conflict I need to merge staging to main and resolve the conflict. But this contradicts with GitLab flow.

You don't actually need to do that in order to resolve the conflict. Instead, do the merge on another temporary branch. For example, create a new branch off of staging, merge main into it, resolve the conflicts, commit the merge, and then merge that temporary branch into staging. When you're done you can delete that temp branch just like you would delete a feature branch after merging it into main.

Note I suggested starting the temp branch with staging and merging in main, rather than the other way around as you suggested. Although the end state will be the same either way, I tend to always start from the branch I am attempting to merge into (aka the target), so that the branch retains the same first-parent history as if you were able to merge main into staging cleanly without conflicts. This is especially helpful if you end up using a fast-forward merge of the temp branch into the target (in this case staging). If you were using --no-ff for merges (like in Git Flow), then it probably wouldn't matter which side you start the temp branch from. GitLab Flow with Environment Branches doesn't say whether or not to use --ff or --no-ff, but based on what I've read about it I think I'd prefer to use fast-forward for all merges into Env branches (all branches except main) whenever possible, and if you do that you'll want your temp branch to start from the target branch.

Side Note: I just want to point out that the GitLab Flow documentation starts off with a mention of (what they perceive as) the problems with Git Flow, and one of them is the complexity of separate release and hotfix branches:

The second problem of Git flow is the complexity introduced by the hotfix and release branches. These branches can be a good idea for some organizations but are overkill for the vast majority of them. Nowadays, most organizations practice continuous delivery, which means that your default branch can be deployed. Continuous delivery removes the need for hotfix and release branches, including all the ceremony they introduce.

Although I agree with much of that paragraph, I disagree that the "complexity" introduced by hotfix and release branches is a problem. Either you need them or you don't. I can see the benefits of GitLab Flow if you don't need them, but when you do need them, the GitLab Flow way to handle hotfixes IMHO is actually more complicated than the way Git Flow handles hotfixes. My point here is that GitLab Flow seems to work best when you don't need hotfixes. Perhaps your scenario is rare, but if it starts becoming the norm, you may want to consider switching strategies.

user_1845460
Related