Git Tutorial EclipseCon France 2014 - Gerrit Exercise 4 - review change
- 1. Review a Change In this exercise you will do a code review in Gerrit. Preparation ● follow the exercise 2 to create an open change in Gerrit. You can review your own change or a change created by somebody else. In practice you will usually review changes created by other developers and others will review your changes. Therefore, try to find a change (for egit-training) not created by you and use it for this exercise. A review of a simple change is usually done in the Gerrit UI. However, for a more complex change you may want to fetch it into your local Git repository, build and test it and look at it in Eclipse. Review the source code changes from Gerrit A change may consist of one or more patch sets. Each patch set corresponds to one Git commit. Newer patchsets replace previous ones when the author reacts on review comments by improving the previous patchset and creates a new commit using “commit amend” to replace the previous commit. When a change has more than one patch set it is only necessary to review the latest patch set since it’s the one replacing all previous ones within the same change ! This is an important principle in Gerrit to remember. Steps: ● Look at the list of files under the latest patch set (patch set 1 in this case). These are the files that were added, modified or deleted within this change. ● click the Side-by-Side link of a file to open a page displaying the changes done in this file. The left side shows the “old version” and the right side shows the “new version” of the file. The diff is highlighted:
- 2. ● Think about every change you see ● If you want to comment on a line just double click it and type in your comment: ● Click Save in order to save the (draft of) your comment ○ NOTE: the comments you create are not yet visible to anybody else but you. Only when you publish your comments they will become visible to everybody. ● Continue reviewing other files in the same way
- 3. Review the commit message Providing a good commit message is as important as writing good code. A good commit message should describe why (the motivation) and not what. When months or years later you look at a change in your Git history you will easily see what was changed. However, only if the commit message was good we will know why this change was made. Therefore, Gerrit also provides review of the commit message. It is done the same way as reviewing a file and the commit message appear at the top of the file list: Vote and Publish Comments ● Click the “Up to Change” link to go back to the change screen ● Click the “Review” button ● Vote in the “Code Review” category
- 4. ● Vote +1 in the “Verified” and the “IP Clean” categories. Normally, this is not done by the code reviewer but we don’t have IP review for the egit-training project. If you are running against http://git.eclipse.org/r/ the Verified vote will be done by a Hudson job which is verifying all changes pushed for review. ● Write the cover message and click the “Publish Comments” button: You are done with the review! Now the author of the change can read your comments and provide an improved new patchset in the next review iteration. The next chapter shows another possibility which is useful when reviewing more complex changes: Fetching the change into local repository When a change is more complex you may want to fetch it into your local Git repository in order to look at it from Eclipse. In that case you may build it locally, debug it etc... To fetch a change first note the numerical change ID of it. Look at the URL of the change in the web browser and locate the numerical Change ID: In this case it is 4445. In Eclipse right-click the Git repository node and select Fetch from Gerrit…:
- 5. In the “Fetch a change from Gerrit” dialog enter the Change ID:
- 6. Press Ctrl-Space for auto-completion and choose the first item from the list by either pressing the Enter or by double clicking the item: Choose “Checkout FETCH_HEAD”. This will checkout the fetched change but will not create a local branch. This is enough if you are not going to contribute further modifications of the change. Now, you have the change checked out locally and your working tree reflects the state the author of the change had when he committed this change. Note that the code review and sharing a change happens before the change gets submitted into the main code base. Copyright © 2014 by C. Halstrick, E. Kempin, S. Lay, S. Zivkov, M. Sohn