Git Flow, pull requests, multi-destination branches and conflicts: how is it supposed to work?

Question

I get it for feature branches:

• A feature branch is created from develop.
• One single PR is then created, going to develop.
• If there are conflicts, fix them in the feature branch.

Quite straightforward.

Concerning "multi-destination branches" though, like release or hotfix branches, how are conflicts supposed to be resolved? Say for example with a hotfix branch:

• A hotfix branch is created from master.
• Question: two PRs are created, one going to master, and one going to develop, right?
• Then, question: what if there are conflicts? For example, the branch does not conflict with master, but it does with develop: where to resolve them? Do we need two distinct branches so that master doesn't receive the conflict resolutions that were needed for develop?

Boss level: a hotfix branch when a release branch is ongoing. Does this case need three PRs: to master, develop and the release branch?

Answer 1

Please, take a look at the picture below:

Usually the above scheme is what I try to follow on the projects I participate.

Then, question: what if there are conflicts? For example, the branch does not conflict with master, but it does with develop: where to resolve them? Do we need two distinct branches so that master doesn't receive the conflict resolutions that were needed for develop?

IMO, that "hotfix" flow should be an exception scenario. In other words, ideally it shouldn't happen very often. I guess it's preferable to release another "official" version, containing only major bug fixes if necessary, rather than performing fixes and immediately putting them back in the production branch (master).

However, if you're following exactly this hotfix scenario, I think that you should indeed create one pull request targeting master (without closing your hotfix branch), and after this merge happens (with your team reviewing the PR, and on which most likely there won't be any conflicts since there aren't parallel people committing stuff to master branch), you create a second PR targeting develop, solving your conflicts on the hotfix branch, if necessary (this time, closing the source "hotfix" branch).

Boss level: a hotfix branch when a release branch is ongoing. Does this case need three PRs: to master, develop and the release branch?

In this scenario, in my opinion (based on the "Bugfixes may be continuously merged back into develop" part from the diagram), you should merge the hotfix to the release branch, because it will eventually be merged back into develop, and it already should contain only bugfixes (the hotfix is nothing but a fix performed on production).

Answer 2

You could solve this by.

Branching out of master for HotFixes. Once the hotFix is implemented, merge the branch to master.

Now cherry pick the merge commit from you develop branch.

Answer 3

I feel I should prefix my answer by saying that I'm not a fan of Git Flow - I think it overcomplicates things, and trunk based development is preferable.

That said, I think I can answer your specific question. Git Flow is described in A successful Git branching model by Vincent Driessen.

Drissen provides instructions for Finishing a Hotfix branch, which includes the following command line instructions:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1

Next, include the bugfix in develop, too:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1

Your question is where to resolve conflicts. Git will prompt you to reserve conflicts during each merge. Any conflict resolutions created during the merge to master will only be on the master branch. Separate conflict resolutions are created during the merge to develop, and those will only be on the develop branch.

In any case the situation where a hotfix branch conflicts with both master and develop seems unlikely to arise. A hotfix is normally a small change, developed in a short period of time. The master branch changes relatively infrequently - only when a release or hotfix is finished. Conflicts only arise when the same part of the code, is changed in both of two branches in the time between the diverging and being merged back together.

Answer 4

Personally, I've had the best luck with avoiding "multi-destination branches".

Release branches are created off of develop. After the release, the release branch is merged into master and then master is merged into develop. During the release cycle with work being done toward the release, develop progresses normally. Hopefully there aren't too many changes to the release branch between creating it and the actual release into master - if there are, this is something I'd want to look into correcting.

Hotfix branches are created off of master. Depending on your distribution model, you may not even need to use a separate branch. If you're only supporting the most recent release, you can use the release branch for hotfixes until the next release comes out. You merge your changes into master and then merge master into develop after the hotfix is deployed. If you have a release ongoing, then you would need to merge from master into both develop and the release branch.

In both cases, you would merge develop into any feature branches that you have at the developer's discretion. It may be useful to communicate when master is merged into develop for this reason.

In any event, if you have conflicts, you would create a second branch to resolve the conflicts in and merge that branch into develop (or the release branch).

This isn't exactly Gitflow, but it seems to be far more robust, yet not a significant deviation from the standard practices.