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.

Improve this question
5
  • 1
    Rebase the development branch against the new version of the main branch.
    – raptortech97
    Nov 20, 2014 at 12:47
  • 1
    What do you use for version control? git, svn, hg, etc..?
    – Izkata
    Nov 20, 2014 at 15:15
  • @Izkata We use ClearCase...
    – compie
    Nov 20, 2014 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, 2014 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, 2014 at 13:44

1 Answer 1

Reset to default
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.

Improve this answer
4
  • 1
    asker didn't tell what VCS they use, what if it is something other than git?
    – gnat
    Nov 20, 2014 at 15:54
  • @gnat We use ClearCase...
    – compie
    Nov 20, 2014 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, 2014 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, 2014 at 21:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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