GitFlow is merging unwanted aspects of master into develop on hotfix finish

Question

We're using GitFlow with a fairly standards setup where we have:

• Master representing latest production
• develop representing ongoing development
• a number of hotfixes under hotfixes/x representing in-flight bugfixes
• a few features under features/x representing in-flight larger features for the next version.

We do have a few differences between develop and master in that we want master to point to certain versions of NuGet dependencies for example while develop points to other versions of those dependencies.

What we're finding is that when we do a GitFlow Hotfix and go to finish that hotfix, at the point at which it merges from the hotfix branch into develop, it will try to merge these configuration differences from master into develop, even though these configuration changes were not done as part of the hotfix.

My coworker asserts that this hiccup is likely a side effect of the master branch being formed by branching from develop when we initially moved to GitFlow instead of us using the GitFlow Releases feature.

Does anyone have any experience with this type of a setup or symptom or have any suggestions to try to attempt to resolve it? We were considering trying to recreate master via using the GitFlow Release feature or using Git attributes to ignore the files for merge, but it feels like there might be a saner way of resolving this.

Answer 1

This is caused by the fact that your configuration on master was changed somewhere since the "merge base" between master and develop. (The "merge base" is, roughly speaking, the most recent commit in the history of both master and develop.) I'd say that means your coworker is on the right track. It doesn't strictly matter whether you use particular GitFlow tooling, but develop should've been branched from master (not the other way around), and (perhaps more importantly) changes should not be applied directly to master.

If those statements seem unreasonable to you, then what you have is not, as you suggest, "a fairly standard setup" for GitFlow.

In a GitFlow setting, dependency versions are not all that different from any code change. Only a few things would normally happen:

The most common thing should be, a feature needs a dependency (or new version of a dependency), so that change goes into the build configuration on a feature branch. From there it eventually merges to develop, then is carried on a release branch that gets merged into master.

Another possibility is that a version number is changed in a hotfix, because you need a security patch or something on a dependency. Of course that should be merged to both master and develop.

Lastly, you could change the dependencies on a release branch; but again, these changes would be expected to merge to both master and develop.

The common theme is, these should all generally converge toward a common configuration. This is not by mistake; if you're claiming to want the versions to stay different in prod, then you're saying you don't want your developers to ever be able to do accurate and effective testing.

If you follow gitflow, then the only reason develop would have a different version of a dependency vs master is that the change hasn't yet flowed to master; and in that case, a hotfix merge is not going to think the master version should override the develop version because the merge base will be on the master version.

Of course there are elements of configuration that should be persistently different between the production and development environments (e.g. connection strings). My advice is to address this problem in your build process rather than your source control workflow.