In this blog, you'll learn how to do code reviews with Git — and why you need a code review tool for Git.
Why Git Code Reviews Are Important
Git code reviews are important for many reasons:
- Making sure the code works and meets requirements (automated testing helps with this, too).
- Coaching new developers.
- Ensuring transparency across teams.
- Sharing innovation.
- Improving performance.
Doing these reviews properly can save time in the long-term. They’ll help you identify bugs and improve quality earlier in development — before testing begins.
Back to topTypes of Code Reviews
There are two primary types of code reviews used today:
Formal reviews are more robust and structured. These are best suited for situations where human lives or national security is at stake if something goes wrong.
Lightweight reviews happen more quickly. These use methods such as over-the-shoulder, email-pass-around, pair programming, and tool-assisted.
Back to topModern Git Code Review
Set up your Git code reviews for success with the right (free) tools. Use Helix TeamHub for free.
Code Reviews With Git
Most code reviews today are done using a code hosting and collaboration tool. (Helix TeamHub is a great example.)
If you aren’t using a tool, here’s what you’ll need to do.
1. Clone the Repository
First, you’ll clone the repository where you will contribute code onto your local workstation. Cloning is common in Git. It’s done to create a local copy of the repository.
2. Branch and Merge Properly
Next, you’ll want to make a local branch for your work, so you can keep your work separate from the branch residing on the code host. Following proper branching and merging practices is important.
When you’re done with your work (bug fixes or new code), you’ll push your branch up to the code host, using the Git push command.
3. Create a Merge/Pull Request
Now, you’ll need to share the code you’ve just written, so it will become part of the work of the team. Depending on the code host, this will be a merge or pull request. Generally, this is done in the web interface of the code host.
In most systems, the path to getting your code merged is through a code review. This ensures the changes are reviewed before they are merged. It’s best to write a clear description of the changes you’ve made in the merge or pull request, so the reviewer knows what to review.
More Code Review Best Practices >>
Back to top
Can You Do a Git Code Review Without Pull Requests?
You can do a Git code review without pull requests, but most code hosting tools require it. So, doing a Git code review without a pull request might not be the best option.
For instance, if you’re using GitHub or Bitbucket, you’ll use pull requests for code reviews. But your team might use a different workflow than “pull request” to manage contributions. In this case, you may want to add another tool to manage the code review process. That can add more complexity to your workflow.
Back to topHow to Improve Your Git Code Review Workflow
The best way to improve your Git code review workflow is to use the right tools. Here are some things to keep in mind if you want to improve your workflow.
Require Code Reviews Before Merging Changes
To protect your project, you’ll want to require code reviews before merging changes.
And you’ll want to come up with naming conventions for branches that developers create, so others on the team can identify them easily. When a developer is ready to merge a branch into the master branch, they can request a merge.
Before the merge goes into the Master, one or more reviewers will examine the changes in the code review interface. Once they are done reviewing, then the changes will be merged into the Master. At this point, the developer’s branch may be deleted. Or they will continue to work in that branch. It depends on your workflow.
Make Reviews Accessible to Global Teams
Over-the-shoulder reviews work great when an entire development team is in the room together. But that type of code review doesn’t work for teams spread around the world.
Using a code review tool makes it easier for teams around the globe to participate in code reviews. Even if you’re working in different time zones.
Set Up an Effective Workflow
Setting up an effective workflow is key. Especially if you’re dealing with a large, distributed team. Things can quickly get out of control with multiple developers and 100s of commits a day.
Here’s a quick walkthrough of how the Git code review workflow works in Helix TeamHub:
- Sign up for Helix TeamHub and set up a Git repository.
- Create a feature branch.
- Add a new code review.
- Check the details of the code review.
- Review changes.
- Follow the status on the discussion tab.
Integrate with CI
The most efficient workflows involve integrating with CI.
For example, with Helix TeamHub, a developer submits a code review. That code can be built and tested in CI, with a build runner such as Jenkins. The code will only go into code review IF the build/tests passes.
By integrating code reviews with CI, you can make the workflow more efficient. By the time the code gets to a reviewer, it will be cleaner, with fewer bugs to fix.
Back to topGet Started With a Code Review Tool For Git
A Git code review tool needs to help you automate and manage code reviews in your Git repositories.
Get started with a smarter Git code review tool — Helix TeamHub.
Helix TeamHub helps you:
- Enforce a code review workflow (i.e. make it obligatory to review codes before merging).
- Keep a history of the code reviews.
- Keep everyone up-to-date with development.
- Make it easier to involve other developers in the process.
Git merge requests are easy and efficient in Helix TeamHub. You can set up feature branch workflows and quality gates to block changes that aren’t approved by team members. Plus, you can require a certain number of reviews, and specific reviewers.
Plus Multi-Repo Code Reviews
Do you need to make changes to multiple repos that must be merged and pushed into production simultaneously? For example, you might have front-end, back-end, and database code.
With Helix Team Hub, you can make sure all the requirements for each of the separate systems are satisfied. Then you can merge all the approved changes in one action — atomic merging — and push them into production together.
You can create one code review that encompasses work being done by team members across multiple repos. Each individual commit in the review can be required to:
- Pass a build.
- Be reviewed.
- Satisfy assigned tasks.
- Be approved by a specified number of developers.
This ensures that the entire set of the changes for each system is thoroughly examined before atomically merging.
Interested in getting started with Helix TeamHub for Git code reviews (and even multi-repo code reviews)? You can try it free for up to 5 users.