采摘樱桃后的 Azure DevOps 拉取请求

Question

I'm working with Azure DevOps and running into a situation with git and a Pull Request I can't understand and looking for help.

Here is the scenario:

• I have two branches: dev, stage.
• dev has numerous commits which have not been merged into stage.
• file.txt exists in both branches; there are three commits (123,124,125) in dev which have mutated this file so it is content wise different than stage.

I cherry pick commit 123 from dev with a target branch of stage into a topic branch. The topic branch is then pull requested into stage.

I then repeat this process for commit 124 and 125 from dev.

If I compare file.txt in the dev branch to file.txt in the stage branch they are now identical content wise.

If I submit a pull request in Azure DevOps from dev to stage on the Files tab of the pull request it is showing me the proposed changes to file.txt as if the dev commits had never been cherry picked into the stage version of file.txt.

I realize that when I cherry pick, a new commit is created within stage so the stage branch does not realize commits 123,124,125 from dev have been applied -- but shouldn't the Azure DevOps File view know the content of file.txt is the same?

Answer 1

That happens because the diff that you see there is not between the source branch and the target branch. The diff is between the source branch and the point where the source branch and the target branch diverged ..... so, you might have modified the file in the target branch in subsequent revisions after the branches diverged. It doesn't matter, the diff in the PR in azure devops (well, at least that's the sane way it works in github and gitlab) doesn't care about them.

Tip: think of it as a diff not done git diff target source but rather git diff target...source (with 3 dots)... and it is done like that because if you did it with a default diff, the diff of the work in a PR would be a moving target. It would always change as new revisions are introduced into the target branch... and you would see things that are not related to the work that was carried out in the source branch (which would make code review HELL) and it is definitely not what git will try to get into the target branch if you try to merge (the merge process involves comparing how the 2 branches have changed since they diverged so no point in checking the diff between the two tips of the branches).