Gerrit/Tutorial
This is a tutorial which explains how to use Git and Gerrit for Wikimedia development.
- If you want to save time and are tech-savvy, use the very short how-to guide instead: Gerrit/Tutorial/tl;dr
- For power users, Gerrit/Advanced usage has additional documentation.
- If you only want to play with Gerrit and do not want to write a patch for a "real" Wikimedia software project, use our Gerrit test instance instead.
In this tutorial, commands to enter start with a dollar sign in a box, like this: command.
Do not enter the $ prefix.
If a command also includes a variable which you must change yourself, then the variable is shown in red: command variable.
What is Git?
Git is a free and open source distributed version control system. “Distributed” means that there is no central copy of the repository. With Git, once you’ve cloned the repository, you have a fully functioning copy of the source code, with all the branches and tagged releases at your disposal.
What is Gerrit?
Gerrit is a free, web-based collaborative code review tool that integrates with Git.
Basically: You submit your proposed software change (often called "patch", in Gerrit called "changeset") as a new branch. If the first version ("patchset 1") is not yet perfect, you can make more changes ("amend") in that branch ("patchset 2", etc.). Once a patchset receives a "+2" review, it will get accepted and merged into the main branch of the code repository (usually called "master"). Merging means that your change is included by default when anyone checks out or downloads that code repository.
Create a Wikimedia developer account
If you do not have a Wikimedia developer account yet, go to wikitech.wikimedia.org and create an account. The same username and password will be used to log into Gerrit below.
Set up Git
These instructions explain how to install Git as a command-line (terminal window) tool. If you prefer a graphical user interface (GUI) instead of the command line, then check the list of clients maintained by the Git project. For alternate installation instructions see the official documentation.
Installation
Linux
- Use the graphical software package management tool of your Linux distribution to install the
gitpackage. - If git has not been packaged by your distribution, then please ask in a support forum of your distribution.
Windows
- Install Git for Windows from https://gitforwindows.org/. This gives you Git, plus a shell called "Git Bash" that allows most of the command lines in these instructions to work on Windows.
macOS
- Install the Homebrew package manager and then run the command
brew install git– This is recommended, as it allows simple updating and easy installing of other packages. - As an alternative, you can install the stand-alone Git for Mac.
Configure Git
Now that you have Git installed, it’s time to configure your personal information. You should have to do this only once. You can also change your personal information at any time by running these commands again.
Git tracks who makes each commit by checking the user’s name and email. In addition, this info is used to associate your commits with your Gerrit account.
Enter the two commands below to set your username and email address. Replace gerrituser with your own Gerrit username and replace gerrituser@example.com with your own email address:
git config --global user.email "gerrituser@example.com"
git config --global user.name "gerrituser"
git config -l.
Set Up SSH Keys in Gerrit
We use an SSH key to establish a secure connection between your computer and Gerrit. To make sure whether you need to generate a brand new key, let's check if an SSH key already exists on your system. Run this command in a terminal:
ls ~/.ssh
The command will list the files that are in the (hidden) .ssh directory.
If the directory already exists on your system and if the output lists a file called id_rsa.pub, then you can go directly to #Copy your SSH Public key.
Generate a new SSH key
To generate a new SSH key, open Git Bash, then enter the command below and replace gerrituser@example.com with your own email address. We want the default settings so when asked to enter a file in which to save the key, just press enter.
ssh-keygen -t rsa -C "gerrituser@example.com"
Enter a strong and unique passphrase and press the [Enter] key.
- Why do passphrases matter?
- Passwords aren’t very secure. If you use one that’s easy to remember, it’s easier to guess or brute-force. If you use one that’s random it’s hard to remember, so you might write the password down. Both are very bad. This is why you’re using ssh keys. But using an ssh key without a passphrase is basically the same as writing down that random password in a file on your computer. Anyone who gains access to your drive has gained access to every system you use that key with. That's why you also add a passphrase. To not enter a long passphrase every time you use the key, there’s a tool called
ssh-agent. It can save your passphrase securely. If you use macOS or Linux, then your keys can be saved in the system’s keychain to make your life even easier.
- Passwords aren’t very secure. If you use one that’s easy to remember, it’s easier to guess or brute-force. If you use one that’s random it’s hard to remember, so you might write the password down. Both are very bad. This is why you’re using ssh keys. But using an ssh key without a passphrase is basically the same as writing down that random password in a file on your computer. Anyone who gains access to your drive has gained access to every system you use that key with. That's why you also add a passphrase. To not enter a long passphrase every time you use the key, there’s a tool called
The ssh-keygen command will create 2 files in ~/.ssh directory:
~/.ssh/id_rsa: your private SSH key (for identification)~/.ssh/id_rsa.pub: your public SSH key
Copy your SSH Public key
Get the content of your public key file (e.g. id_rsa.pub) to copy it to your clipboard:
One option is to open your public key file with your favorite text editor (Notepad, TextEdit, gedit, etc.).
In the file chooser dialog of your text editor, you may need to turn on “View hidden files” to find the file, because the .ssh directory is hidden.
Sometimes the “View hidden files” option is available by right-clicking in the file chooser dialog.
Other options are:
- On Linux, run
cat ~/.ssh/id_rsa.puband manually copy the output to the clipboard. - On Windows, you can open Git GUI, go to Help 🡒 Show Key, and then press "Copy To Clipboard" to copy your public key to your clipboard.
- On macOS, you can run
pbcopy < ~/.ssh/id_rsa.pubto copy the contents of the your public key file to your clipboard.
It’s important you copy your SSH Public key exactly as it is written, without adding any newlines or whitespace. Copy the full text, including the "ssh-rsa" prefix, the key itself, and the email address suffix.
Add SSH Public key to your Gerrit account
- Log into the web interface for Gerrit. The username and password for your Gerrit are the same as for your Wikimedia Developer account.
- Click on your username in the top right corner, then choose "Settings".
- Click "SSH Keys" in the menu on the left.
- Paste your SSH Public Key into the corresponding field and click "Add".
Add SSH Private key to use with Git
Start the Git Bash command line.
- Get ssh-agent running using
eval `ssh-agent`- Be sure to use the accent
`, not the single quote'. (You could copy and paste from this page if you cannot easily enter this special character.)
- Add your private key to the agent.[1] If you followed the steps above and your key has the default name
id_rsa, then the command is:
ssh-add ~/.ssh/id_rsa
- Connect to the Gerrit server via
sshto check if everything works as expected. Replace gerrituser by your username as shown in your Gerrit settings:
ssh -p 29418 gerrituser@gerrit.wikimedia.org
- Be paranoid and compare that the "RSA key fingerprint" is the same as the SSH fingerprint for gerrit.wikimedia.org:29418. If it is the same, answer "Yes" to "Are you sure you want to continue connecting?". Then enter the passphrase for your key.
- You should get a message "Welcome to Gerrit Code Review". The last line should show "Connection to gerrit.wikimedia.org closed."
- If you run into problems, use
ssh -p 29418 -v gerrituser@gerrit.wikimedia.org(replace gerrituser by your username). The-vwill provide verbose output to help find problems. Then read Gerrit Troubleshooting.
An example Gerrit SSH connection success message looks like this:
Example:gerrituser@machine:/mw/sandbox$ ssh -p 29418 gerrituser@gerrit.wikimedia.org The authenticity of host '[gerrit.wikimedia.org]:29418 ([208.80.154.85]:29418)' can't be established. RSA key fingerprint is dc:e9:68:7b:99:1b:27:d0:f9:fd:ce:6a:2e:bf:92:e1. Are you sure you want to continue connecting (yes/no)? yes Warning permanently added '[gerrit.wikimedia.org]:29418 ([208.80.154.85]:29418)' (RSA) to the list of known hosts. Enter passphrase for key '/home/gerrituser/.ssh/id_rsa': **** Welcome to Gerrit Code Review **** Hi gerrituser, you have successfully connected over SSH. Unfortunately, interactive shells are disabled. To clone a hosted Git repository, use: git clone ssh://gerrituser@gerrit.wikimedia.org:29418/REPOSITORY_NAME.git Connection to gerrit.wikimedia.org closed. gerrituser@machine:/mw/sandbox$
Download code using Git
Let's practice by downloading (also called "cloning") the repository called "sandbox". Run the following on the Git Bash command line:
git clone ssh://gerrituser@gerrit.wikimedia.org:29418/sandbox
(Replace gerrituser by your Gerrit username. And make sure the URL begins with ssh: and not https:).
This will copy the entire history and the code base of the "sandbox" extension repository onto your machine.
You will have a working directory of the extension's main branch (usually also called "git master").
Enter the new directory (via the command cd sandbox).
Now you can look at the code and start editing it.
Prepare to work with Gerrit
Gerrit requires that your commit message must have a "change ID".
They look like Change-Id: Ibd3be19ed1a23c8638144b4a1d32f544ca1b5f97 starting with an I (capital i).
Each time you amend a commit to improve an existing patch in Gerrit, this change ID stays the same, so Gerrit understands it as a new "patch set" to address the same code change.
There's a git add-on called git-review that adds a Change-ID line to your commits. Using git-review is recommended. It makes it easier to configure your Git clone, to submit a change or to fetch an existing one.
Installing git-review
Note that Wikimedia Gerrit requires git-review version 1.27 or later.
For more details, please see Gerrit/git-review#Installation.
Linux
- Use the graphical software package management tool of your Linux distribution to install the
git-reviewpackage. - If git-review has not been packaged by your distribution, check git-review for other options such as installing git-review by using the pip Python package installer.
- If you use FreeBSD, install git-review through ports.
Windows
- Please see git-review Windows.
macOS
- For OS X 10.11 El Capitan and later, follow Method 1.
- On versions prior to 10.11, use the pip Python package installer by following Method 2.
Configuring git-review
Git's default remote host name is "origin". This name is also used by Wikimedia projects. We need to tell git-review to use that host. Replace gerrituser with your Gerrit username:
git config --global gitreview.remote origin
git config --global gitreview.username gerrituser
Setting up git-review
After downloading ("cloning") a repository, you need to set it up for git-review. This will automatically happen the first time you try to submit a commit, but it's generally better to do it right after cloning. Make sure that you are in the directory of the project that you cloned (otherwise you will get an error "fatal: Not a git repository"). Then run this command:
git review -s --verbose
Towards the end of the output, you should see something like this:
Example:Found origin Push URL: ssh://gerrit.wikimedia.org:29418/PROJECT Fetching commit hook from: scp://gerrit.wikimedia.org:29418/hooks/commit-msg 2019-02-19 12:40:16.712892 Running: scp -P29418 gerrit.wikimedia.org:hooks/commit-msg .git/hooks/commit-msg
This may ask you for your git username, if it's different from the shell username you're using.
git-review, then you could use the Gerrit patch uploader or Editing via the web-interface to submit a patch.
Submit a patch
Make sure that you cloned the code repository that you are interested in (see here).
Make sure that you are in the directory of the code repository (the command pwd tells you where exactly you are).
Update master
Make sure that your master branch (the branch created when you initially cloned the repository) is up to date:
git pull origin master
However, note that a few repositories use different terms (for example, the operations/puppet repository has a production instead of a master branch).
Create a branch
First, create a local branch for your new change.
Replace BRANCHNAME below by a short but reasonably descriptive name (e.g. T1234 if a corresponding Phabricator task exists for your changes, cleanup/some-thing, or badtitle-error).
Other people will also use this name to identify your branch.
git checkout -b BRANCHNAME origin/master
Example:gerrituser@example:~/dev/mw$ git checkout -b mentionWikimedia origin/master # Switched to a new branch 'mentionWikimedia' gerrituser@example:~/dev/mw$ git branch * mentionWikimedia master
This will create a new branch (called BRANCHNAME) from the latest 'master' and check it out for you.
In the example above, we called that new branch mentionWikimedia.
Make your changes
Make changes to your local code.
Use your preferred text editor and modify a file.
In the example below, we edit the file README.md and add a word.
Then close your text editor and check the changes you have made since the last commit, within the file(s) and within the directory:
git diff
Example:gerrituser@machine:/mw/sandbox$ git diff diff --git a/README.md b/README.md index 1d25b27..bc54021 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Hello world! -You can make test changes and experiment with Gerrit in this repository! +You can make test changes and experiment with Wikimedia Gerrit in this repository! Don't worry about messing this repository up; it is meant for testing. gerrituser@machine:/mw/examples$
git diff displays your changes in unified diff format: Removed lines have a minus (-) prefix and added lines have a plus (+) prefix.
These changes are not yet "staged" (via git add) for the next commit.
Stage your changes for a commit
Run git status to decide which of your changes should become part of your commit.
It will display a list of all file(s) that you have changed within the directory.
At this point, the output will display "no changes added to commit" as the last line.
Use git add to make your changed file(s) become part of your next commit.
In the example above we modified the file README.md, so the command would be:
git add README.md
Any files you've changed that you have not passed to git add will be ignored when running git commit in the next step.
git status.
After you ran git add, git status will not show the line "no changes added to commit" anymore.git diff --cached to see which changes are staged and will go into the next commit.
The output will look the same as for the git diff command above.Commit your staged changes
Once you are happy with the list of changes added via git add, you can turn these changes into a commit in your local repository by using
git commit
sandbox/.git/COMMIT_EDITMSG:Short subject line More details. The blank line between the subject and body is mandatory. The subject line is used to represent the commit in code-review emails, search results, git-rebase, and more. Bug: T999999 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch mentionWikimedia # Your branch is up to date with 'origin/master'. # # Changes to be committed: # modified: README.md
You will then be asked in your text editor to add a descriptive summary for your commit. You must follow the Commit message guidelines. This is what other people will see when looking at the history of changes in the code repository.
Save the commit message and close your text editor. A summary (the commit ID, your subject line, the files and lines changed) will be displayed.
When you git commit, you are committing to your local copy.
Prepare to push your commit to Gerrit
Synchronize your changeset with any changes that may have occurred in the master branch while you've been working ("rebasing"). From within your branch, run:
git pull --rebase origin master
Example:gerrituser@machine:/mw/sandbox$ git pull--rebase origin master From ssh://gerrit.wikimedia.org:29418/sandbox * branch master -> FETCH_HEAD Current branch mentionWikimedia is up to date. gerrituser@machine:/mw/sandbox$
git pull --rebase origin master will fetch new commits from the remote and then rebase your local commits on top of them.
It will temporarily set aside the changes you've made in your branch, apply all of the changes that have happened in master to your working branch, then merge (recommit) all of the changes you've made back into the branch. Doing this will help avoid future merge conflicts.
Plus, it gives you an opportunity to test your changes against the latest code in master.Now you are ready to push your code to Gerrit for review. If you made several related commits, consider merging them into one single commit for review.
Push your commit to Gerrit
If you followed #Prepare to work with Gerrit above and installed git-review and ran git review -s, then the command to push changes to Gerrit is:
git review -R
The -R option tells git-review not to perform a rebase before submitting the change to Gerrit.
Example:gerrituser@machine:/mw/sandbox$ git review -R Creating a git remote called 'gerrit' that maps to: ssh://gerrituser@gerrit.wikimedia.org:29418/sandbox.git Your change was committed before the commit hook was installed. Amending the commit to add a gerrit change id. remote: remote: Processing changes: new: 1, done remote: remote: New Changes: remote: https://gerrit.wikimedia.org/r/#/c/sandbox/+/563720 Test for https://www.mediawiki.org/wiki/Gerrit/Tutorial remote: To ssh://gerrit.wikimedia.org:29418/sandbox.git * [new branch] HEAD -> refs/for/master%topic=mentionWikimedia gerrituser@machine:/mw/examples$
Upon success, you'll get a confirmation and a link to the changeset in Gerrit. In the example above, that link is: https://gerrit.wikimedia.org/r/#/c/sandbox/+/563720
Congratulations! Your patch is in Gerrit and hopefully will get reviewed soon!
View the Change / Next Steps
Open the link to your Gerrit changeset in a web browser.
Under "Files", after you clicked the down arrow at the very right of any file in the list, you can see a diff of your changes per file: The old lines are shown in red color and your new lines are shown in green color.
If your commit addresses a ticket in Phabricator, a comment will be automatically added in the Phabricator task if you followed the Commit message guidelines. If you did not, you could either fix your commit message (by creating an updated patchset), or manually add a comment on that Phabricator ticket which includes a link to your changeset in Gerrit.
Other common situations
Also see Gerrit Advanced usage if your situation is not covered here.
Squash several commits into one single commit via rebase
If you made several related commits to your local repository prior to wanting to submit for review, you should squash (merge) those commits into one single commit.
The --interactive or -i option allows you to change (rewrite) your commit history.
For each commit, you can modify and change the commit message, add or remove files, or perform other modifications.
First you need to tell git how far back you want to pull. To get a list of all changes in your branch:
git rebase -i origin/master
You can also limit the displayed list of recent changes. HEAD~3 means pull the last three commits:
git rebase -i HEAD~3
After you type this command, your text editor will display your commits in reverse order and a list of available commands:
Example:pick aa8cf1d Adding method customFilterFunctionGetRiskyCountryCodeScore() to GatewayAdapter. pick 38828e2 Adding $wgDonationInterfaceCustomFiltersFunctionsRiskyCountries to donationinterface.php pick be33007 Fix a typo # Rebase 95ccd28..be33007 onto 95ccd28 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. #
Since we only want to send one commit to review, we will squash the last two commits into the first. Hence change all but the first "pick" to "squash":
pick aa8cf1d Adding method customFilterFunctionGetRiskyCountryCodeScore() to GatewayAdapter. squash 38828e2 Adding $wgDonationInterfaceCustomFiltersFunctionsRiskyCountries to donationinterface.php squash be33007 Fix a typo
When you finished picking and squashing and saved the file, another file will open in your text editor to allow you get to edit and merge your commit messages. Be careful to only keep one of the Change-Id lines and have it be at bottom of the message after one empty line.
Your messages from your previous commits will automatically be placed in this message:
Example:# This is a combination of 3 commits. # The first commit's message is: (mingle-fr-2012-69) Adding a custom filter for risky countries. Adding method customFilterFunctionGetRiskyCountryCodeScore() to GatewayAdapter. # This is the 2nd commit message: Adding $wgDonationInterfaceCustomFiltersFunctionsRiskyCountries to donationinterface.php # This is the 3rd commit message: Fix a typo Change-Id: I33e44ec0d93628d9a53c15e08eb89f352b7d5fe0 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # Not currently on any branch. # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: donationinterface.php # modified: gateway_common/gateway.adapter.php #
Remember to put your (updated) summary message in the commit. In this case the new summary message will be:
(mingle-fr-2012-69) Adding a custom filter for risky countries.
If all goes well, you should see a successful rebase message:
Example:[detached HEAD 02f5e63] (mingle-fr-2012-69) Adding a custom filter for risky countries. 2 files changed, 92 insertions(+), 3 deletions(-) Successfully rebased and updated refs/heads/mingle-fr-2012-69.
Afterwards, submit your patch for review:
git review
You should see a message like this showing your git review went to Gerrit (in this example, to https://gerrit.wikimedia.org/r/7187):
Example:remote: Resolving deltas: 100% (4/4) remote: (W) 02f5e63: commit message lines >70 characters; manually wrap lines remote: remote: New Changes: remote: https://gerrit.wikimedia.org/r/7187 remote: To ssh://gerrituser@gerrit.wikimedia.org:29418/mediawiki/extensions/DonationInterface.git * [new branch] HEAD -> refs/for/master/mingle-fr-2012-69
Amending a change (your own or someone else's)
Sometimes, you might need to amend a submitted change. You can amend a change as long as the change hasn't been merged yet.
You can amend your own changes. To amend changes submitted by someone else, you need to be a member of Gerrit's Trusted-Contributors group. To become a member of Trusted-Contributors, find someone who is a member and ask them to add you. The group is viral in that members can add new members, use your powers responsibly.
Rebase to bring your local branch up to date with the remote. It's best to make rebase updates a separate patch, so that your code reviewers have an easy time seeing what changes you've made. Assuming you are using Gerrit, you can do this by clicking the "Rebase Change" button when viewing your patch in Gerrit's web interface.
Hard reset and checkout the change with this command:
(BEWARE: git review -d performs a hard reset that destroys all local changes. Stash or commit changes first which you wish to preserve!)
git review -d changenumber For example: git review -d 9332
Note, if you already have the change in a branch on your local repository, you can just check it out instead:
git checkout BRANCHNAME For example: git checkout review/gerrituser/2012/bug12345
Next, make some changes with your favorite text editor.
git add the files as needed, then commit the change (ensuring you are amending the commit):
git add Example/Example.body.php
git commit --amend
-m flag to specify a commit summary: that will override the previous summary and regenerate the Change-Id.
Instead, use your text editor to change the commit summary (in the file .git/COMMIT_EDITMSG if needed, and keep the Change-Id line intact.Push the change:
git review -R
The -R is important here.
It tells git-review to not rebase your change against master, which clutters diffs between patch set 1 and 2.
Push to a branch different than master
Above, the commit was pushed to the master branch.
The branch name only appeared as the topic of the commit in the Gerrit UI.
If you really want to push to a different branch than master, you have to push via git review <branch name>.
Editing via the web-interface
If you're logged in to Gerrit, you can also create code changes directly within the web interface. This can be useful for making small patches, or for non-developers to contribute small fixes.
- Go to https://gerrit.wikimedia.org/r/admin/projects and choose the code repository that you want to edit.
- Select "Commands" in the sidebar
- Click "Create Change"
- Set branch to "master" (if you don't want to use master branch you can use the other branches available for that project)
- Set the topic to something of your choosing (e.g. "copy-edit" - must be all-one-string) (optional)
- Write a description ("commit summary") in the big text field by following message guidelines. (Example)
- Click "Create"
- In the upper right corner, click the "Edit" button
- Under "Files", click "ADD/OPEN/UPLOAD" button
- Type the folder/file path for the file you wish to edit (e.g. i18n/en.json) and click "Confirm"
- Find the line(s) you want to change, and change them.
- Click "Save"
- Click "Close"
- Click "Publish edit"
- Click "Mark as active" to remove the "Work in Progress" status from your code changes
Done!
If you need to change the commit message of an existing changeset, you can use these steps:
- Go to the changeset itself. Example URL: https://gerrit.wikimedia.org/r/c/1234567890 (replace the ID at the end)
- In the "Files" section, click "Commit message"
- In the upper right corner, click the "Edit" button
- Make changes to the commit summary.
- In the upper right corner, click "Save"
- In the upper right corner, click "Close"
- In the upper right corner, click "Publish edit"
Gerrit & Vagrant
MediaWiki-Vagrant is a portable MediaWiki development environment and is readily usable with git-review and gerrit.
After installing MediaWiki-Vagrant use cd to navigate to your extensions folder.
Then follow the instructions above on submitting a patch via gerrit.
How code is reviewed in Gerrit
Code review is an essential part of our contribution workflow. The principle is basic: any patch must be reviewed by others before being merged.
This means that your code will need reviewers. Check our advice for getting reviews.
Review before merge
It's important to us to have a review-before-merge workflow for MediaWiki core and also for any extension we deploy. We will also offer that option to any extension author who wants it for their extension. The one exception is localisation and internationalisation commits, which will be able to be pushed without review.
Who can review? Gerrit project owners
After creating a Developer account, anyone can comment on commits and express criticism and approvals. Anyone can give a nonbinding "+1" to any commit. However, for any given repository ("Gerrit project"), only a small group of people will have the ability to approve code within Gerrit and merge it into the repository. This superapproval is a "+2" even though that's a misleading name, because two +1 approvals DO NOT add up to a +2. These people are "Gerrit project owners".
How to comment on, review, and merge code in Gerrit
Anyone can comment on code in Gerrit.
Viewing and commenting on code
- Make sure that you have a developer account.
- Log in to Gerrit. If you know the changeset you want to look at (URL will look like https://gerrit.wikimedia.org/r/#/c/23939/), go to that. Otherwise, use the search box. You can search by author ("Owner"), Gerrit project, branch, changesets you've starred, etc. The Gerrit search documentation covers all of the different search operators you can use.
- The changeset has a few fields, links and buttons:
- Assignee. An optional field to make a single person responsible for handling reviewing the changeset. This should only be set if the assignee has agreed.
- Reviewers. 'jenkins-bot' is the autoreviewer that auto-verifies anything that passes the Jenkins tests. It will report a red or green mark depending on whether the build passes.
- The "Add reviewer" button under Reviewers: in the upper left corner manually request review from someone. It'll show up in their Gerrit dashboard.
- Under Files, Expand All opens the diff for each file below. You can double-click on a line and then press the C key to comment on that line, then click "Save" to save the draft comment. Then, at the top of the page click the "Reply" button to publish your comment.
- Reply adds your comments to a changeset, including an overall comment and/or inline comments you added (see above).
- If, upon code review, you approve, use "Code-Review:
+1" under "Reply"; otherwise, use "Code-Review:-1" to disapprove. These numbers are nonbinding, won't cause merges or rejections, and have no formal effect on the code review.
- If, upon code review, you approve, use "Code-Review:
- Abandon (you'll see this if you wrote this diff). This action removes the diff from the list to review, but leaves it in Gerrit for archival purposes.
- The "Only Comments" switch allows to hide reviews by non-human bots. See https://phabricator.wikimedia.org/T48148#6294913 for an example.
Comparing patch sets
Every time you amend your commit and submit it for review, a new patch set is created. You can compare the different patch sets like this:
- Under Files, select either Expand All or choose a specific file listed to open that file.
- On the left side under Patch Set, Base is preselected. On the right of the screen under Patch Set, the latest patch set is preselected. Adjust the selected patch sets to your needs.
Formally reviewing and merging or rejecting code
If you are one of the Gerrit project owners, you'll also see:
- Abandon button
- under Reply, additional Code-Review options to +2 (approve) or -2 (veto) a diff, and a Post button (publish your comment and merge diff into the branch, in 1 step)
- Submit button (merge -- only useful if you or someone else has already given a +2 approval to the diff, but not merged it)
And once you've merged something into the example Gerrit project you'll see it in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/examples/.
If you merged a commit that references a task in Phabricator and that commit is supposed to fix that task completely, please go to that task and change its status to "Resolved" (via the Add Action… 🡒 Change Status dropdown). Also reference the merge ID if gerritbot has not already posted it in that task.
Troubleshooting
For problems and how to solve them, see Gerrit/Troubleshooting.
See also
Also useful are these pages:
- MediaWiki Git Guide (MGG) - selection of relevant Git pages in the MediaWiki Virtual Library
- Official Gerrit documentation
- Git/Gerrit FAQ
Third party guides to Git
- Video tutorials how to use Git (on Wikimedia Commons)
- An intro-to-git "training mission"
- Try Git (interactive demo)
- GitMagic A git guide with translations
- A git branching model
- Git: the simple guide
- Git Community Book will take you gently into Git internals. (It is hard to "get" git until knowing something about how it works internally.)
- Git's website with documentation
- Another useful OpenStack Git guide (if you subtract away GitHub stuff)
- Understanding the Git Workflow by Benjamin Sandofsky
- Using Git in Eclipse
- Why to fetch/merge instead of pull by Mark Longair
Historical documents
- An introduction to git-svn for Subversion/SVK users by Sam Vilain
- Git for Subversion users by IBM
- How we're going to use Git slides by Brion Vibber, as presented autumn 2011
- Audio from Git presentation by Brion Vibber, autumn 2011
- Notes from Brion Vibber's presentation
References
- ↑ If as a Ubuntu user you have a "Permission denied (publickey)" message, please check on this help page