1

At my current job we develop code on a release branch and then do a code review. After all rework is done the final changes are also synced/merged to the 'main branch'. We want to be sure that all changes are synced correctly. What's a good way to review this sync work?

Note: the initial versions of files in the release branch and 'main branch' can be different. Thus it doesn't always help to compare the latest version in the release branch with the latest version in the main branch. (You then still see the 'initial differences' between both branches, although you don't see any 'sync changes' anymore).

My idea was to compare the 'delta' on the release branch with the 'delta' on the main branch. By using the GNU diff tool I can generate these two delta's, and then compare them in a file compare tool. Is this a good idea?

Note: we use ClearCase.

Just to clarify: We can't (or don't want to) rebase the release brach to the main branch, just for code review. That would again be a possible way to make mistakes. The release branch contains the code which our customers run. The main branch is used for splitting of new release branches in the future.

  • 1
    Rebase the development branch against the new version of the main branch. – raptortech97 Nov 20 '14 at 12:47
  • 1
    What do you use for version control? git, svn, hg, etc..? – Izkata Nov 20 '14 at 15:15
  • @Izkata We use ClearCase... – compie Nov 20 '14 at 20:59
  • If you're not going to merge the release branch back into the main branch, why do you care about the "sync"? When does this "sync" eventually happen? – raptortech97 Nov 21 '14 at 2:03
  • @raptortech97 We do merge the release branch back to the main branch. This is called 'the sync'. My question is about the review of this sync. Note: What we don't do is merge all the (other) changes in the main branch back to the release branch. – compie Nov 21 '14 at 13:44
2

You should update your version of the main branch against the latest version of the main branch, pulling in changes that have occurred since you branched off for your feature branch. Once this is done you can then compare your differences alone.

Example using git:

First git rebase (or git merge but I prefer git rebasein case of code conflicts) the feature branch against the main branch. You will need to resolve any code conflicts.

Then you can do a git diff directly to the main branch.

n.b. Do a git fetch first to make sure you are doing your rebase/merge and diff against the latest version of the main branch.

I don't know the syntax for ClearCase but the process will likely be similar.

  • 1
    asker didn't tell what VCS they use, what if it is something other than git? – gnat Nov 20 '14 at 15:54
  • @gnat We use ClearCase... – compie Nov 20 '14 at 20:59
  • @compie I see. Is this answer helpful for you? I ask because I doubt that git rebase / git merge / git diff / git fetch mean anything in ClearCase – gnat Nov 20 '14 at 21:10
  • Excellent point folks! I've updated my answer to be more general and to use the git commands as an example in git rather than "the answer". Good catch! – Michael Durrant Nov 20 '14 at 21:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.