0

We see incorrect branch differences in TFS (git repository). We follow a typical scenario between dev and release branch:

  • Create a "release" branch from current "dev" and deploy it for testing.
  • Fix a few bugs within "release" branch. Each bug is fixed by branching from "release" into its own hotfix branch and getting the code back via pull request. To ensure that every hotfix also gets back into "dev", we cherry-pick every completed PR from hotfix to "release", and PR it again into "dev".
  • Now "release" branch state is signed-off by QA as ready for production, and we need to ensure that "develop" contains all the changes and nothing is missing. We compare "release" and "develop" in TFS web, and try to create a PR from "release" to "develop".

Expected behavior: no changes are needed to be pulled from "release" to "develop" as every single change was already pulled there in its own PR.

Actual behavior: every single hotfix we made into "release" displays as code difference between "release" and "develop" - even though actual code lines are THE SAME.

Questions:

1) Are we doing something wrong here? 2) How can we see the ACTUAL changes pending from "release" to "develop" due to the hotfixes?

Richard
  • 106,783
  • 21
  • 203
  • 265
Dmitry Korolev
  • 31
  • 5
  • Branch differences in the Azure DevOps (VSTS) portal are based on common commits, but when cherry picking there is no common commit. – Richard Sep 21 '18 at 09:19
  • So how do we get _actual_ differences that need to be rolled back into dev? Do we need to change our procedure to be able to do that? – Dmitry Korolev Sep 21 '18 at 10:15
  • Once you're using `cherry-pick` you'll need to use `git diff relese..dev` because you can't work at the common commit level. – Richard Sep 21 '18 at 11:56
  • Do we need to do this for _every_ cp-ed commit? This would be very tedious (practically unusable option). Can this be achieved within TFS Web UI without involving manual tools? – Dmitry Korolev Sep 21 '18 at 14:39
  • That depends on the details of the process. Personally I try and avoid cherry picking because it means the "same" change is two (or more) completely independent commits, and most tooling assumes one change one commit. – Richard Sep 22 '18 at 09:09
  • We can change the process. The idea is: once the "release" branch is signed off, we need to make sure that all hotfixes made within that branch are made it back into develop. We will create a pull request for this, and as a part of this pull request we need to see ACTUAL code difference. – Dmitry Korolev Sep 25 '18 at 13:10
  • So this is either a problem so uncommon there is no answer, or a problem so common that answer is not deemed interesting by anyone? – Dmitry Korolev Sep 29 '18 at 20:25
  • Have to take it as "no known answer to a seemingly common and widespread problem". OK. – Dmitry Korolev Nov 30 '18 at 11:21

0 Answers0