Pull request shows old commits after rebase/merge to another branch in azure devops

Question

We are trying to adapt Skullcandy git flow - link

In short the flow is:

1. Feature branch is rebranched from master
2. After work on the feature is finished code is rebased/merged to QA branch were it can be additionally tested if needed (Pull request is created here and code review is done)
3. After tests are finished we rebase/merge the feature branch to master using another Pull request

Now we have problems with both merge and rebase using this approach .

Rebase approach:

1. We create PR to QA and master (1 additional commit)
2. We complete PR to QA using rebase fast-forward
3. After PR to QA is completed suddenly PR to master can show additional commits which didn't exist there before. If I would remove the branch from origin and push it again from local repository and create new PR to master it shows 1 additional commit again correctly

I'm not sure why this happens. It seems almost like feature branches commit history is rewritten. I'm also not sure if this approach is feasible at all since rebase can create new commit SHA's so they can be shown as changes.

Merge approach:

1. We create PR to QA and master (1 additional commit)
2. We complete PR to QA and master using merge
3. Problem that occurs here is that since merge created one additional Merge commit after we rebranch from master again for new feature and create new PR to QA it shows Merge commit from master as change. It also shows all the changes done in that merge commit in the code review pane which is problematic.

I'm guessing this problem occurs because SHA of merge commits are different on QA and master branches?

Summary

Can you help me to understand why rebase behaves the way it does ?

Are there any suggestions as to how we can improve our flow ?

We would prefer the master only flow but for that we would need autogenerated testing environments for automated tests and we are not there yet :)

Answer 1

I was just looking for an answear for this, and found this Microsoft response.

They claim it's a feature - not a bug.