Currently, we have the following branches:

1. Develop: Internal master
2. Staging: Customer review
3. Master: Production

The flow is featureBranch -> Develop -> Staging -> Master

I'd have liked to not allow direct push to any of these branches- but only through a pull request.

Since we rarely push to staging, master branches, we have been creating our branches from the develop branch.

and thus before creating a PR, we take a pull from develop into the featureBranch.

Now, when it's time to merge develop to staging or staging to master, we have conflicts. and I'd not want to push to these branches directly, but only through a pull request.

What am I doing wrong? How can this be resolved?

CodePudding user response：

A conflict arises because two different branches have both changed the same file. If the only commits on "staging" were merged from "develop", there will not be any conflicts.

There are two common reasons why a pair of long-lived branches would have conflicts (I'll use the example of "develop" and "staging" here; the same applies to "staging" and "master".)

1. There are changes on "staging" which aren't on "develop". Sometimes, you may need to fix something while testing the "staging" branch, so you merge it directly to the "staging" branch. At some point, that change needs to make its way to "develop" as well - otherwise it will be broken every time someone tests there. For git to know it exists on both, that needs to be a merge from "staging" to "develop", not just applying the same changes.
2. You used the wrong type of merge. If you use a "squash merge", git completely ignores the history of the branch being merged, and creates a single commit containing all its changes. Some people like to do this to keep their history "tidy", but you should never use a squash merge with a branch you're going to carry on useing. Because the squashed commit doesn't reference the history of the other branch, git doesn't know those changes are already on both branches, so when you merge again, it tries to apply them all again.

The solution in both cases is the same:

1. Merge all changes from the "staging" to "develop", and resolve the conflicts there. Repeat this whenever you make a change to "staging" that didn't come from "develop".
2. Make sure you use a "true merge" / "merge commit" for that merge, and for all future merges between "develop" and "staging".

CodePudding user response：

1. Having conflicts is it normal state

2. For merge you need to resolve conflicts otherwise you may lost your changes using direct push.

3. For feature branch dev need to resolve conflicts

4. For develop -> staging -> master team need to review changes and resolve conflicts