Very recently we moved over to a "Git Flow" approach, where we make use of develop, release, and main branches. Recently we created a main branch from the same commit as the most recent release branch. Every time we merge a release branch into main, we then merge main into develop, usually with a new branch off of main where we resolve conflicts first (since they're protected branches).

However, with the newest release branch created off of develop, we have conflicts between release (which is just develop at this point) and main. Resolving these conflicts is just a 0 file change PR, but I don't understand why there are even conflicts in the first place. I've drawn the most recent history to try further demonstrate the process:

Git process

Note that all of those merges are squashed

Any help would be much appreciated!!

CodePudding user response：

If you are using standard Git Flow, you should never have merge conflicts when merging release into main/master. If you do have conflicts, something is wrong. The reason conflicts shouldn't exist is because the only two ways for commits to appear on main are from the release branch, or a hotfix. In the case of a hotfix merging into main, immediately afterwards you should merge main back into release if a release branch exists, and if it doesn't, you should merge main back into develop. This way release will always be ahead of main.

With standard Git Flow, the only time you should ever potentially have conflicts are when merging:

• main back into release (hotfix conflicts with release)
• main back into develop (release/hotfix conflicts with develop)
• release back into develop (release conflicts with develop)

If you are having conflicts merging release into main, the most likely reason is you have a hotfix on main that didn't get merged back into release immediately afterwards, and skipping this step is potentially dangerous because if you deploy the release branch to production directly, you won't have those hotfix changes in it.

Regarding this text in your diagram:

At some point, trying to merge develop into main results in merge conflicts.

I assume you meant "merge main into develop" rather than the other way around, since there isn't actually a flow of develop directly into main. It's perfectly normal to have conflicts when merging main down into develop, which typically happens when the same files are modified on both develop and the release branch after it branches off. That's just a normal course of development unless you are willing to implement code freezes.

Process Problem:

Note that all of those merges are squashed

This doesn't seem right. That's definitely not part of Git Flow, and in general you never want to rewrite commits on long-lived/protected branches. That means commits on develop, release, hotfix, and main/master should not be squashed. The only time it might make sense to use squash with Git Flow would be when merging feature branches into develop or release, if you don't care about the specific commit information on the feature branches.

Side Note regarding this statement:

Every time we merge a release branch into main, we then merge main into develop, usually with a new branch off of main where we resolve conflicts first (since they're protected branches).

This is a minor point, but bravo for merging main back into develop after merging release into main. Standard Git Flow suggests actually merging the release down into develop instead of doing it from main there, however, it doesn't make a difference from a code standpoint, and doing it the way you're doing it is IMHO cleaner and slightly more efficient in the long run. It's one of the few tweaks I always recommend to the Standard Git Flow.