We use gitflow methodology, so master branch, dev branch, feature branches. For release we merge dev to master and release from there.

What is happening is that each time we go to PR dev to master, we are told dev is one commit behind master and we can't merge. So we PR master to dev. It shows no diff and merges fine. Then we can PR dev to master. But the cycle repeats for the next release, even though we haven't done anything to master.

What should I be looking for that could cause this?

CodePudding user response：

If you're using the standard Git Flow, then you will have a merge commit on master when merging in a release branch. (Note, in your case it sounds like you're skipping release branches for now and instead you just have a dev branch which would be akin to develop in Git Flow.) So, every time you merge dev into master you will get one new merge commit on master.

From your comment:

If we merge dev to master, they should both be pointing at the same commit (If I understand my git right).

Not necessarily. That would be true if you allowed a fast-forward merge, but that's not true if you force a merge commit. However, the state of dev and master should be the same after the merge.

Regarding his comment:

"Why can't you merge?" Well, bitbucket won't let us. Probably could force it or something, but seems like that wouldn't solve the problem.

That is probably because you have a setting turned on in BitBucket that requires dev to be fully up to date with master. Note this is unrelated to Git merges in general and the requirement isn't necessary if you don't want it.

If you want to leave that setting on, I would recommend doing the back merge of master to dev immediately after merging into master, instead of immediately before. This way if you ever have a hotfix that gets merged into master your process will get that hotfix merged down into dev right away, so your testing against the dev branch can include it.