A kickoff guide to streamline your code using Gerrit
This post covers most of the rudimentary questions one can encounter when starting working with Gerrit. The views are based on personal experience and it is an attempt to elucidate the basic Gerrit workflow. Any suggestion is sincerely accepted.
How to develop on a backlog?
For a robust and clean code never code directly in the master branch. For every backlog item or message you are working on, create a new branch.
How to push the code to Gerrit?
After development in your branch and committing the changes,
- Switch to the master branch
- Pull the latest changes in the master branch
- Go back to your backlog branch, rebase master. This will bring your latest commits on the top and all the conflicts if any will be shown.
- Now merge the local branch to master and push. Always amend the commit.
How to create a patch set in case of a review comment?
There can be many ways to handle such situations but due to limitations of the setup and to prevent any conflicts, this is one of the approaches that can be used:
- Go to Gerrit UI to your change request.
- Click download and copy the EGit Id (Picture 1).
- Go to eclipse, switch to the master branch. Right click> Fetch from Gerrit and use the EGit Id to create a new branch from the change. Make your changes and amend to the commit.
There can be a chance that in the course of your review and amend, there is a potential conflicting code that has been merged by someone else. To protect your code from conflicts, continue as follows:
- Switch to master and reset it to refs/remotes/origin/master and take a pull. This will make your code same as on the remote master.
- Now continue the same procedure to push the code to Gerrit.
This will be the most generic method that should work even when you have deleted the backlog branch, otherwise you can simply reset the master, make amends in the backlog branch, rebase and merge.
What to do if your backlog item gets frozen for the sprint and you want to preserve your code?
Push the code to Gerrit and abandon the change. When you want to develop it again, use the above process and continue.
What to do if you see conflicts in Gerrit that hinders the merge?
Contact the owner of the change with whom you are facing the conflicts. Figure it out with the owner. Typically, one of you has to rebase the code (Picture 2) and other has to wait till it gets merged, pull the changes, solve conflicts and push it again amending the same commit.
Leave the input field empty to rebase to the master.
When will the submit button to merge the code appears?
Once a commit has the maximum score in each category and no minimum scores in any category, it can be merged. The default categories are Code Review (-2 to +2) and Verified (-1 to +1). So to merge a commit, it must have a +2 Code Review and +1 Verified score, and no -2 Code Review or -1 Verified scores.