Gerrit/Tutorial

Right now Git/Workflow is a better tutorial - this page is to develop a good hourlong step-by-step tutorial for the Berlin Hackathon 2012.

What is Git?
Git is a distributed version control system (dvcs) written in C. A version control system allows the creation of a history for a collection of files and includes the functionality to revert the collection of files to another state. Another state might be a different collection of files or different content in the files.

You may, for example, change the collection of files to a state from 2 days ago or you may switch between states for experimental features and production issues.

The collection of files is usually called "source code". In a distributed version control system everyone has a complete copy of the source code (including the complete history of the source code) and can perform version control operations against this local copy. The use of a dvcs does not require a central code repository.

If you make changes to the source code you mark them as relevant for the version control (add them to the index / staging) and then add them to the repository (commit).

Git maintains all versions. Therefore you can revert to any point in your source code history using Git.

Git performs commits to your local repository and you can synchronize your repository with other (remote) repositories. Git allows you to clone repositories, e.g. create an exact copy of a repository including the complete history of the source code. Owners of repositories can synchronize changes via push (transferring changes to a remote repository) or pull (getting changes from a remote repository).

Git supports branching, e.g. you can have different versions of your source code. If you want to develop a new feature, you may open a branch in your source code and make the changes in this branch without affecting the main line of your code.

Git can be used from the command line; this approach will be described in this tutorial. You also find graphical tools, for example EGit for the Eclipse IDE, but these tools will not be described in this tutorial.

Basics
Why did Wikimedia engineering moving from Subversion to Git Three major reasons: To encourage participation: Since Git is distributed, it allows people to contribute with a much lower barrier to entry. Anyone will be able to clone the repository and make their own changes to keep track of them. And if you’ve got an account in our code review tool (Gerrit), you’ll be able to push changes for the wider community to review. To fix our technical process: Subversion has technical flaws that make life difficult for developers. Notably, the implementation of branching is not very easy to use, and makes it hard to use “feature branches”. Our community is very distributed, with many parallel efforts and needs to integrate many different feature efforts, so we’d like to use feature branches more. Git branches are very easy to work with and merge between, which should make things easier for our development community. (Several other large projects, such as Drupal and PostgreSQL, have made the same switch for similar reasons, and we’ve done our best to learn from their experiences.) Some quotes from our community: “I love git just because it allows me to commit locally (and offline).” – Guillaume Paumier “[Y]ou can create commits locally and push them to the server later (great for working without wifi), you can tell it ‘save my work so I can go do something else now’ in one command, and it’ll allow us to review changes before they go into “trunk” (master)…. without human intervention in merging things into trunk. Gerrit automates this process.” – Roan Kattouw And finally, to get improvements to users faster: with better branching and a more granular code review workflow that suits our needs better, plus our ongoing improvements to our automated testing infrastructure, we won’t have to wait months before deploying already-written features and bugfixes to Wikimedia sites.

On Ubuntu you can install the Git command line tool via the following command: sudo apt-get install git-core
 * Demo of setting up Git
 * General Git distro info
 * Installation

For other Linux distributions please check your vendor documentation.

A windows version of Git can be found on the msysgit Project site.

The URL to this webpage is http://code.google.com/p/msysgit/.

Download
You can currently download MediaWiki core using Git, as well as any extension currently installed on the Wikimedia Foundation server cluster. By July 2013, all extensions will either be available using Git or move to alternate version control hosts.

The first step is to clone the MediaWiki repository.

Enter in the following on your command line: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git




 * Use the most recent Release-Upgrade for current security and new features
 * Category:MediaWiki Releases
 * MW Release Notes
 * submitting a patch
 * commenting on a patch in Gerrit
 * merging a patch in Gerrit

Collaborating

 * Gerrit project ownership - brief mention that there is a commit/abandon and how they can qualify for the permissions to do this.
 * something got tagged - what does that mean?
 * branching
 * local branch, making, working & pushing
 * remote branch & git-review to that remote branch
 * | Git Review
 * quick overview/invitation to building your review skills

Installing git-review
First, install the release version of git-review using python package installer : $ sudo apt-get install python-pip $ sudo pip install git-review





Note: if you don't have  but have   installed, you can use this: $ sudo easy_install pip $ sudo pip install git-review pip

Setting up git-review
After cloning a repository, you need to set up for using 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. $ git review -s This may ask you for your git username, if it's different from the shell username you're using.

Internally, this does the following:
 * checks whether accessing the remote repository works
 * if it doesn't, asks for a username and tries again
 * creates a remote called 'gerrit' that points to gerrit
 * installs the commit-msg hook


 * Code Review process
 * | Old SVN Code Review article

Troubleshooting

 * cherrypick changes between branches
 * amending (rebase vs multiple commit)
 * | Managing Conflicts in Gerrit Repo (Merge or Rebase)
 * | Rebasing, empty commits, empty cherry picks
 * squashing work from a branch into a commit and pushing it
 * resolve merge conflicts

Deployment
If we have time to discuss.

Collection of Helpful Git/Gerrit Resource (please add to and incorporate these articles)
Old SVN download article
 * Localization: are these incorporated yet?
 * Is this bug fix incorporated in all MW Git/Gerrit documentation?
 * Git_notes_-_NOLA_Hackathon_2011.oga
 * Git_notes_-_NOLA_Hackathon_2011.pdf
 * Git Notes from NOLA hackathon - good distillation; only inaccuracies are around submits and Git review tool.