Pre-Commit vs Post-Commit Review

Code review is commonly acknowledged to be one of the development stages that greatly helps to increase software quality. It helps to optimize code, to detect and fix bugs early before they get to QA. And the earlier the bugs are detected the cheaper they are to fix.

There have been two methods of peer review: formal (or heavyweight) and lightweight. Formal code review takes meetings, printed copies of code, takes much of company's resources and keeps developers from actually developing the product. It gets the job done, but also slows down the development process.

Lightweight peer code review, on the contrary, is less formal and can (and must) be a part of the common development process. Lightweight code inspection can be divided into the following types:

Pair programming – two authors develop the code together at the same workstation
Over-the-shoulder – the code's author gives a walkthrough to a colleague
Email pass-around – reviewers receive code changes sent by the source code management system via e-mail, after check-ins are made
Tool-assisted code review

This article focuses on the tool-assisted or automated peer code review .

What is Post-Commit and Pre-Commit Review?

In this regard, there are two types of code review: pre-commit and post-commit. Pre- and post-commit review concepts are quite self-explanatory: pre-commit is a type of review when the code is reviewed before it goes to the main repository of the version control system. Post-commit review takes place after the code has been submitted to the public repository.

Have a look at some of the advantages and disadvantages of these two review types before deciding which one to adopt.

Pre-Commit Reviews

Pros:

Company's coding quality standards are met before the work is committed to the main repository
This scenario helps to make sure the review has been performed, not postponed or omitted
Pre-commit reviews ensure other developers in your team won't be affected by bugs that may be found during a review

Cons:

Decreases productivity of each developer, since further work on the submitted code is impossible until a successful review, and takes even longer if multiple reviewers are involved
After successfully passing a review, the developer could commit a different piece of code , by mistake or otherwise

Post-Commit Reviews

Pros:

A developer can work and commit changes to the repository continuously
Other team members see the code changes and can alter their work accordingly
Some changes can be complex and require multiple steps, so it's convenient to examine each step separately after all of them have been committed

Cons:

Increased chances of poor code making it into the main repository, hence affecting the entire team's work
When defects are found, it may take a while for the developer to switch back to the module they had been working on

Conclusion

We've had a quick glance on the pre- and post-commit review types, their differences, up- and downsides. Developers' opinions are divided on which type of code review to use, and both camps adduce valid arguments in each side's favor. But all disputes come to the same point: code review type application depends on the particular project conditions.

What is the best thing to do?

Both types have their upsides and downsides, each is being applicable to different projects , different team sizes and other variables. The above mentioned aren't the only advantages and disadvantages of the two approaches. Many development teams employ a hybrid approach: inspect major or core changes before they are committed to the main repository, and post-commit review trivial changes. But it also raises the question of how to define the 'trivial'.

Good review practices include:

Committing early and often. It's far easier to run multiple small reviews than a single huge one
Encouraging developers to produce well-documented code before review is issued
Committing code to a 'test' branch first and pushing it to the main one after it successfully passes the review
Tracking defects in order to make sure they are actually fixed after the review
Reviewing the code, not the authors

What code review tools to use?

If you need a lightweight and flexible solution for post-commit reviews, try out Review Assistant to enhance your post-commit code review process and increase development efficiency while retaining simple workflows.

Besides integration with code comparison tools, our code inspection tool includes lightweight support for formal review workflows, a defect-tracking system and VCS integration, which will be helpful for:

Frequent code check-ins
Large teams working in the same company
Smaller teams, dispersed geographically
Developers that want to save time on formal review meetings