1

The company policy where I work is that code cannot be committed to SVN until a code review is complete. This is sensible enough as we don't want broken code ending up in the repo, but it does give us some headaches from time to time.

The main issue is this:

  1. I make changes to file1 for ticket A.
  2. Put up for review.
  3. While review is ongoing, begin work on ticket B.
  4. Ticket B needs changes to file1.

When this happens I have to temporarily shelve my changes for ticket A and start work on ticket B. When the review for ticket A is complete I shelve my changes for ticket B, unshelve ticket A, commit A, unshelve B. As you can tell this is quite tedious.

If ticket B is supposed to build on changes from ticket A, I'm completely blocked.

Since the project I'm working on is only a few months old, we're considering moving from SVN to git, since we can make commits to our local repos while waiting for review.

My knowledge of git is fairly limited though. Is this going to alleviate this situation, or are there any better changes that could be made?

  • 5
    Not putting code into production or even staging before a code review is good practice. Never committing before a code review is counter-productive. If your VCS can't commit locally (which SVN can't), you should still commit to a branch or something similar when you've coded something. – Kilian Foth Apr 8 '16 at 9:36

Your Answer

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

Browse other questions tagged or ask your own question.