User:Dan-nl/Git and Gerrit/The Workflow

tl;dr

The initial git commit and git review of a branch will create a new change set in gerrit.

cd /path/to/<gerrit-project>/
git pull --rebase gerrit master # make sure to resolve any conflicts with the current gerrit master
git review -s # install the git review hooks if not already installed
git checkout -b <branchname> master # create a new branch from your local master
# write your code
git add # add changes you want to commit
git commit # note the difference with subsequent commits
git pull --rebase gerrit master # @see make sure to resolve any conflicts with the current gerrit master
git review --no-rebase

Subsequent git commits and git reviews will create a new patch set within the initial change set.

cd /path/to/<gerrit-project>/
# write your code
git add # add changes you want to commit
git commit --amend  # note the difference with initial commit
git pull --rebase gerrit master # make sure to resolve any conflicts with the current gerrit master
git add # if you had to correct any rebase conflicts
git commit --amend  # if you had to correct any rebase conflicts
git review --no-rebase

regarding git pull --rebase gerrit master

Gerrit & Git

Gerrit implements a different perspective on commits than git. In general :

Gerrit
In Gerrit, each commit is considered a Change-Set that needs to be reviewed before possibly being merged into the master branch. These Change-Sets most likely depend on each other in order for the code to work properly, yet each Change-Set needs to be approved before all of them can be merged into the master branch. Because of this approach, you typically create one Change-Set and modify it by amending commits to it, which create Patch-Sets for that Change-Set. These Patch-Sets can then be approved or discarded. Once all of the Patch-Sets of a Change-Set have been approved, or discarded if necessary, the Change-Set can then be merged into the master branch if final approval by the core team is given.

Git
In Git, each commit is an atomic change that does not need to be reviewed, but continuously contributes to the completion of a development branch. Once work on the development branch is completed, it may then be merged, in its entirety, into the master branch if approved by your team.

Install the git review hooks

git review will install its hook automatically on your first git review in a new project, however, it’s probably best to have the git review hooks already installed before you issue the first git review command.

git review -s

Update master

Make sure that your master branch (the branch created when you initially cloned the repository) is up to date:

git pull --rebase gerrit master

Create a new change set

First, create a local branch for your new change. The branch name should be short, but reasonably descriptive. For example, if you are working on a bug, include its id, "bug/12345", this will show-up in gerrit as a topic of the master branch. The following command, run locally in your master branch directory, will create a new branch <branchname> from ‘master’ and check it out for you.

git checkout -b <branchname> master

Merge with master

If you are the primary author/maintainer of the code and the code has not yet been deployed to the Wikimedia cluster, you can merge the branch with the master branch by reviewing the branch in Gerrit with +2 and verifying with +2; otherwise, someone from the foundation will need to do that for you.

Working on an existing change set

Sometimes you want to work on a change set started by some else and then upload your changes as a new patch set.

# Note in the gerrit URL the number reference to the change set, 
# e.g., https://gerrit.wikimedia.org/r/#/c/70112/, thus 70112

# In your local copy of the master branch, pull down the change set 
# and switch to that branch with the following command.
git review -d 70112

# Make any necessary changes and commit them as an amendment, 
# adding appropriate comments to the commit message.
git commit --all --amend

# Push the patch set up to gerrit as usual.
git review --no-rebase

# Other developers can then update their local copy of the change set 
# with the following command.
git review -d 70112