1GB storage for free, after that 1€/GB / month
Everything is private
All the features you need
Let's first take a look on the Git code review process as a whole and then move to the best practices. This guide will end at demonstrating how you can create code reviews and improve your workflows on Git hosting service Deveo. Following the steps is easy after you sign up to Deveo. Deveo is free to use so there is absolutely no risk!
Roughly put, code reviews can be separated in two different categories; the lightweight code review processes and the formal code review processes. The formal code review process is a more robust, structured, and time-consuming process. It usually includes meetings and thorough examination, which have their place in some industries, especially if human lives or national security are at stake.
However, as the modern software development aims at releasing software in increasingly shorter intervals, more lightweight ways are needed. This has lead to the emergence of such methods as over-the-shoulder, email-pass-around, pair programming, and tool-assisted code reviews.
Despite their differences, both of these serve the same purpose: subjecting code to examination before it is pushed to production. On this guide, we are concentrating on the lightweight code review.
Even though over-the-shoulder code reviews, email pass-arounds, and pair-programming are good ways to do lightweight Git code reviews, tool-assisted code review with a specialised tool is perhaps the most effective option for a Git code review.
Reasons are numerous: code review tools allow you to enforce a code review workflow (i.e. make it obligatory to review codes before merging), keep a log of the code reviews, keep them up-to-date with the development, and make it easier to involve other developers in the process.
For example, in Deveo, you can find all the code reviews from one place, examine the changes, comment them on the code lines, and have discussions. With Deveo’s @mentions you can draw your colleagues attention to the exact place where it is needed, even to a single code line.
Even the lightweight processes mean more work, so why bother doing code reviews at all? You want to publish changes fast, right? Well, truth to be told, proper Git code review actually save time in the long run, even if they add an extra task to your development process.
The importance of Git code review boils down to ensuring the quality of the code. We become blind to our own work and need other people to pinpoint possible errors and conflicts in it. Basically, this means that without a proper code review process, you end up wasting time in fixing bugs, which could have been avoided in the first place.
As a result, you accumulate technical debt or increase the workload of your Quality Assurance (QA) team. It all boils down to that you aren’t performing as well as you could. In the worst case, your sub-par software ends up to customers who aren’t going to wait too long for you to fix your buggy code. This, in turn, will have an effect on your revenue for sure.
So, how well is Git suited to code reviews? Git is a distributed version control system (DVCS), and thus every developer working on the same Git repository has their own local copy of the full version history. Since everyone has the full version history, it makes sense to share the changes with others before pushing them to the central repository. So, thanks to its distributed nature, Git is actually perfect for efficient code review.
The development in Git is typically done using multiple branches. In a nutshell, branching means that you make a copy of the objects, such as source code files, that you want to modify. As a result, developers can work in parallel on multiple different versions of the same code, and finally merge the changes back together when they’ve made the changes.
Before you merge the code changes together you should subject your code for a review. One way to achieve this would be to set up a working culture, in which the code reviews are mandatory. Another way could be to enforce this with proper tools.
Deveo allows you to set up protected branches, which means basically three things:
1. The history cannot be changed
2. The branch cannot be deleted and
3. Only master and admin role can push to them
The role of master and admin can be configured per project or even per repository basis. Thus, by enforcing code reviews with protected branches you can be sure that pushing and merging is done by developers who has the best overall knowledge of the project.
Now that we know what Git code review means, let’s take a look at how a proper Git code review workflow is done. In case you want to watch a video demo instead of reading a detailed post, you'll find a video walkthrough below.
First things first, sign up to Deveo by clicking the button below, and verify your account with the code you got via email. Follow the instructions and create your first project. All of the needed tools and information can be found under the projects. Access your project and navigate to the Repositories view to create a Git repository.
Set up a Git repository by clicking the Plus icon in the top right corner of the repositories view. As you can see from the opening view, Deveo supports also Mercurial and Subversion. We want to do a code review in Git and thus proceed with it. Remember to name your repository.
The empty repository presents you instructions and its cloning path. Clone the repository to your local workstation. Then create a Readme.md file, which will serve as an example. Commit and push it to Deveo. You now have created a master branch with one file and a commit.
We talked earlier about the branches in Git and how they make code reviews work like a charm. Also in Deveo, code reviews are conducted on branches. So next, create a feature branch locally, and make some changes to the Readme.md file or other files you might have created for this exercise.
Commit and push the changes to Deveo, and you’ll see that they have appeared under the created branch in the Deveo UI. If they are not visible, refresh the page. A rule of a thumb is that one code review shouldn’t be more than a few hundred lines. The more code there is the harder it becomes to review. However, reviewing single lines of code isn’t too sustainable either since it takes too much time.
Now, we are finally ready to make our first code review request!
Now that you have pushed code to the feature branch, you want to navigate to the code reviews view in the Deveo UI. Create a new code review by clicking the familiar blue plus icon. Choose the right Git repository, in which you were working, the feature branch that you want to merge and the target branch (main branch).
As code reviews are a joint effort multiple developers, remember to write a proper title and a description so that your peers know what this code review is about. Enable voting, and decide how many approvals the code needs to receive in order to be merged. Sure enough, you cannot upvote your own code review.
On a side note, in Deveo, the project admins can add an extra level of security by protecting branches. This limits the right to push and merge to these branches only to people with project admin and master level permissions. In addition, project admins can also define the number of approvals needed for a passing code review in the repository settings.
After you created the code review in Deveo, Deveo automatically opens the code review details. Your team can see the feature branch and target branch, access the changes, and have discussions. The view also presents how many votes are still needed in order to merge the branches. It also includes all the necessary buttons for merging, upvoting and rejecting the changes.
If you set the number of required approvals, note that the Merge button is disabled until the code review has gotten the required amount of votes. Even after that, the button is enabled only for those project roles that have the permission to merge to the target branch. If you are using protected branches, the merge button is enabled only to project administrator and master roles.
All of the code changes can be accessed from the changes tab. For your viewing pleasure, Deveo lists a summary and the changed files on top of the page for larger code reviews. After opening a file, we can review the changes and comment them on a code line level.
Deveo tracks both the feature branch and the target branch constantly and updates the code review if either is changed. This allows developers to simply commit and push new changes to the same feature branch, or rebase the feature branch, without the need to do a new code review.
The overall status of the code review can be followed in the Discussion tab. The discussion tab logs the comments and other actions in chronological order. When a comment is outdated, it is hidden from the discussion but can be opened if you need to check it later.
Outdated comments are comments for changes that are not part of the latest revision.
When the code is reviewed, and has the needed amount of votes, the merge button is enabled. Branches can now be merged, and the feature branch can be deleted at the same time if it is no longer needed. Hooray! Your code review is ready!
This guide's aim was to give you a proper view on Git code review and present a good workflow for conducting them easily with Git hosting service Deveo’s code review tool.
While pair-programming, email pass-arounds and over-the-shoulder code reviews are decent ways to ensure the quality of the code, you might be better of by using a specialized tool. At least if you plan to grow!
Sign up to Deveo’s free cloud service and try out the Git code review feature. Host unlimited number of Git repositories, have as many projects as you need, and invite unlimited amount of users for free!
The free plan includes 1GB of total data, after that the price is 1€/GB/month.