3

I've been using Git and GitFlow for quite a few years now, but this is still confusing me.

Let's say I open branch release/1.1.1 to let the stakeholders test their application.

While they're testing devs complete 2 new features and merge them on develop.

Meanwhile stakeholders ask for 2 small fixes on release/1.1.1, devs fix them and push them directly on release/1.1.1.

Now they open a PR from release/1.1.1 to develop so that the fixes are included in develop as well.

THERE ARE MERGE CONFLICTS

How can I fix those merge conflicts on the release/1.1.1 branch without also including changes from develop or without overriding them instead?

My hypothesis are:

  1. make fix branches form release/1.1.1 too and make PR from there to release/1.1.1 and then to develop this way merge conflicts will be handled in the fix branch instead of release/1.1.1
  2. push fixes directly on release/1.1.1 and then make a separate branch to handle the PR towards develop so that the merge conflicts will be handled there and not on release/1.1.1 instead

In the picture below isn't really clear how to handle such merge conflicts, I feel my solutions will mess up my history.

enter image description here

1 Answer 1

3

Option 1 is probably more consistent with GitFlow, but I've tended to use a variation on Option 2, but the variation comes from a need to have checks prior to merging into a controlled (release or develop) branch - I'd create a branch for the change, merge into the release branch, and then merge the release branch into develop, with an intermediary branch for resolving merge conflicts if any exist. Since this is usually an exceptional case, the intermediary branch is rarely needed. Your Option 2 could be better for your situation and is what I'd lean toward.

I would also point out that I've typically only seen release branches for major and minor versions. Patches would be additional commits into the release branch, without their own branch. I don't think this has any bearing on your current situation, but it could be something to consider. Instead of having a release/1.1.1 branch, you would have a release/1.1 branch and any 1.1.1 or 1.1.2 patches would be in that same branch.

2
  • Hey, thanks great answer! Just a clarification on your second point: so you don't version counting the new features / fixes on develop? You just add one minor for each release (unless it's not backwards compatible)? Sep 25, 2022 at 15:19
  • 1
    @CarloMoretti I don't know what you mean by "version counting the new features/fixes on develop". There's only main, develop, and release/x.y branches that are long-lived. A patch release x.y.z is a tagged commit on release/x.y that will get merged into main and develop. Of course, you can also drop main and only use develop and release branches for some efficiency, but would move away from GitFlow.
    – Thomas Owens
    Sep 25, 2022 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.