CODEWITHSUNDEEP
gitgit-flow
Matt Eland
Matt Eland

Reputation: 376

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

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

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.

Upvotes: 3

Views: 1435

Answers (2)

max630
max630

Reputation: 9248

Speaking shortly, gitflow implicitly merges whole master to develop, and when you merge it like this, there is a problem of keeping certain changes of master away from develop. (As for your "My coworker asserts..." I did not fully understand it, but it is irrelevant how the branches were started. If they were originally unrelated merge would still aim to make them same, as another answer explains it)

The only thing I can suggest about it is to revert that configuration in develop after merge. Next times when there is change in master it would trigger merge conflict which you could resolve manually in desired way.

Upvotes: -1

Mark Adelsberger
Mark Adelsberger

Reputation: 45819

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.

Upvotes: 3

Related Questions