Introduction to Gerrit
Gerrit is a web based code review tool which is integrated with Git and built on top of Git version control system (helps developers to work together and maintain the history of their work). It allows to merge changes to Git repository when you are done with the code reviews.
It is easy to find out the error in the Source code using Gerrit. As it built on top of Git so, no need to install any Gerrit client. It is an excellent tool which can be used between the developer and Git repositories.
Basic Things you will Study in this Tutorial:
Features of Gerrit
Advantages
Gerrit Code Review System
Features of Gerrit
- Gerrit is a free and an open source Git version control system.
- The user Interface of Gerrit is created on Google web Toolkit.
- It could be a light-weight framework for reviewing each commit.
- Gerrit acts as a repository, that permits pushing the code and creates the review for your commit.
Advantages of Gerrit
- Gerrit provides access management for repositories and web frontend for code review.
- You can push the code with out using additional command line tools.
- Gerrit will enable or decline the permission on the repository level and all the way down to the branch level.
- Gerrit is supported by Eclipse.
Gerrit Code Review System
Gerrit could be a code review system developed for the Git version control system. It is a online primarily based code review system, facilitating online code review systems. Gerrit is a Git server that adds a fine grained access system and a code review system and workflow.
The Gerrit is based on Google web Toolkit. Its uses JGit library to provide the Git functionality.A developer can use Gerrit to suggest a change. Other developers can review the change and suggest improvements. If a Gerrit change needs improvement, it is possible to update it with a new commit. Once the suggested changes are accepted, they can be merged to the target branch of the Git repository via the Gerrit user interface.
Gerrit makes code reviews easier by showing changes in an exceedingly side-by-side show. It additionally supports to show the modification as a unified difference that is commonly easier to browse on smaller screens.
A reviewer can add comments to each single line modified.
Gerrit is licensed below the Apache 2.0 license.
The Gerrit review system uses the term change, to outline a code review / review request. Every modification is based on one commit.
Disadvantages of Gerrit
- Reviewing, verifying and resubmitting the code commits slows down the time to market.
- Gerrit can only work with Git.
- Gerrit is slow and it is not possible to change the sort order in which changes are listed.
- You need administrator rights to feature repository on Gerrit.
Functionality of Gerrit
Gerrit can prevent users from pushing directly to the Git repository.This push ref specification is refs/for/master if the target of the change under review is the master branch. You can also push to refs/for/xyz to put a commit into the review queue for the xyz branch.
If you push to this ref specification, Gerrit creates a new change or makes an update of an existing one. Gerrit uses the Change-Id information in the commit message to identify if the push is a new commit or an update of an existing change.
A change consists of one or more patch sets which are used to improve the first proposal based on review comments. One patch set corresponds to one Git commit.
It is still possible to bypass code review by pushing directly to refs/heads/master if sufficient rights have been granted.
Review Categories – Verified and Code-Review
Gerrit supports different categories (also known as labels) for review feedback.
In typical installations also the Verified category is installed.
The Verified category typically means you were able to build and test the change introduced with the Gerrit change. Typically, this is done by an automated process such as a Jenkins / Hudson build server.
The “Code-Review” category is typically used to vote on the quality of the implementation, code style, code conformity. It also indicates that the change is in accordance with the standards desired by the project.
Committers and contributors can vote in these categories.
Voting in Gerrit
- The rules for voting in Gerrit is:
- Highest vote (+2 in Code-Review and +1 in Verified) enables submitting
- Lowest vote (-2 in Code-Review) is a veto blocking that the change can be submitted and can’t be overruled by other reviewers
- You cannot submit the changes to the Git repository until there is the highest vote in all categories
Typically Gerrit instances uses the Verified and the Code-Review category.
If you did some manual testing and the code works as you desire then it is good to +1 in the “Verified” category. Or give -1 if it failed some of your use cases that must be resolved in order to merge. Otherwise, leave it as 0, if you did not test the code.Non-committers of the project can vote with -1 and +1 to indicate an opinion in either way. But ultimately it is up to the decision of those with +2 power to make the overall decision. You may want to -2 vote to block the submission of the code.
Posting Draft Reviews
There is also a special refs/drafts/master refspec which you can use to push changes to for private review before publishing them to all developers.This is useful if your work is in progress and not ready for public reviews. Once it is ready for public review there is a Publish button to convert the draft into a change review.
In the Gerrit scenario amending a commit is used to update the Gerrit change request. Using the amend operation on a published commit is usually discouraged in Git, in Gerrit it is the normal process.
The Gerrit review system is based on the assumption that each commit is reviewed separately. At GitHub, a complete branch is reviewed and merging with the pull request.
