how to merge released hotfix to develop with conflicts in pull request?

Viewed 2581

We are using the following workflow branches:

  • master
  • develop
  • hotfix branch per hotfix (branched from release tag)

When a hotfix branch is released to production, it is merged back into develop and master via BitBucket pull requests.

Now I need to merge the hotfix branch to both develop and master. I create a BitBucket pull request to develop, but there are merge conflicts blocking it. Simply put the ongoing development modified same files since the release tag was created.

What is the proper way to resolve this?

I'm thinking:

  • creating a new branch from develop
  • cherry-picking commit from hotfix branch to the new branch
  • create pull request to merge the new branch to develop

but it seems like a lot of manual work (in theory - in fact I have maybe 5 commits in hotfix branch) and I'd love to have some easy way to do that that is compliant with git-flow.

2 Answers

In Gitflow, your current suggestion of branching off of develop is exactly what I might use. The goal is for develop to be the one that resolves the merge conflicts. You could just pull in the hotfix branch and commit directly, but if you're wanting to get peer review on the resolution (or are just missing the permissions to commit to develop directly) then you would branch off of develop, pull in hotfix, and then PR back into develop.

Master should always always be release + changes for next release. So unless the hot fix is throw-away (i.e. an emergency hack that needs to be redone properly for the next release), the first thing that needs to happen is that the changes on release need to be merged or applied to master. If that results in a conflict those conflicts need to be resolved properly. By properly I mean logically correctly and the code functions as it should and all tests pass. There is no magic A.I. (yet) that can do that for you -- though there are different merge algorithms that might make it easier/harder, but that's very advanced use of git.

Once the hotfix changes are on master the next step is to repeat the process, this time from master to develop.

Any other flow of changes undermines the whole meaning and purpose of release, master and develop branches.

Related