CODEWITHSUNDEEP
azure-devopspull-request
Mike Hofer
Mike Hofer

Reputation: 17002

Strange merge behavior in Azure DevOps using Git

The business recently planned to test two separate features in the same sprint, but weren't sure if both of them were going to be deployed. Our solution was to create two feature branches off of Develop, one for each feature, and a third branch off of develop ("the Hybrid Branch") into which those feature branches could be merged. We would only deploy to DEV and QA from the Hybrid Branch, allowing dev and QA to test both features. If one of them was pulled back, the individual feature branch would be merged to develop and deployed without the other.

But we've encountered some strange behavior with one of the feature branches when merging into the hybrid branch.

When creating a pull request, Azure DevOps merges every change from the date that the feature branch was created. It's as if the branch doesn't get rebased properly after a push or merge or what-have-you.

For the other feature branch, it pulls only the set of commits pushed since the last merge. This is how we expect it to work.

This makes reviews of the pull request difficult, as it's difficult to isolate the specific changes for the PR. It also means that resolved conflicts have to be re-resolved for every PR, and the PR acts like previously added or removed files need to be added or removed again.

What could be causing this and how do we resolve it?

Upvotes: 2

Views: 1403

Answers (1)

Tuan Pham
Tuan Pham

Reputation: 1110

I think it's because of squashing. The way git works isn't by tracking a "last merged commit pointer". Every time you merge branches, git looks for any commits that are present on one branch and not present on another. It does it by comparing hashes. So if you merge with squash, then those commits are merged to another branch with different hashes, so the next merge will show them as new commits again.

Regarding one branch working properly, maybe the other branch was rebased to the first? You can check hashes of commits to make sure that they are indeed different on both branches

Upvotes: 2

Related Questions