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
Types of Code Reviews
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.
Code Reviews With Git
Most code reviews today are done using a code hosting and collaboration tool.
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.