Basics of Git and Gerrit

Git & Gerrit

• As per British English, Git means “unpleasant person”. The inspiration of designing Git is taken from “BitKeeper” and “Monotone”. 

• Both are distributed revision control system. Git was originally designed as a low level version control system engine and on top of this Cogito and StGIT(Stacked Git) is developed. StGIT is a Python application that provides functionality similar to quilt. 

• Git is a highly performant free and open source distributed version control system as compare and contrast to other centralized version control systems such as CVS, SVN, ClearCase, and Perforce. 

• It was initially designed and developed by Linus Torvalds for Linux kernel development in 2005.

• As per the analysis corresponding to Eclipse IDE users, Git has reported 30% adoption as of 2013 in software industry for VCS(Version Control System)/RCS(Revision Control System)/SCM(Source code management).

• The Stable release of Git is released on August 23, 2013 which is of version 1.8.4. Its Initial release was introduced in the 7^th april 2005 . Originally Git is developed in “C”.

Gerrit

• Gerrit is a free, web-based review tool developed by Google for Android. 

• It is developed with a git based workflow in mind. It acts as a firewall in front of a Git repository. 

• Software developers working in a team can review each other's changes/modifications on their source code using a web browser and approve or reject those changes. 

• Gerrit works on "Change"s. A change is a set of modifications to various files in your repository to accomplish a task. It is essentially one large git commit with all the necessary changes which can be both built and tested. 

• It integrates closely with Git, a distributed version control system. 

• It was developed at Google by Shawn Pearce (founder of JGit) for the development of the Android project. Gerrit uses Google Web Toolkit to generate front-end JavaScript code from Java source. 

• It is a SSH server. 

• Gerrit centralizes the distributed nature of Git, while maintaining the advantages of a DVCS, by imposing a centralized workflow. 

• Large corporations such as SAP, Sony Mobile, Qualcomm and many other enterprises, organisations and non affiliated individuals/volunteers contributed to the review and development of the code-base.

• The Stable release of Gerrit is released on September 18, 2013 which is of version 2.7.   

• Originally this tool was written in Python and now this tool is written in Java, Servlet and GWT. 

• This is a code review tool and now apache is having its license.

The gerrit trigger works like this:

Referenced from http://www.mediawiki.org/wiki/File:GitWorkflow.svg.

1.      It connects to the gerrit server using ssh and uses the gerrit stream-events command

2.      It then watches this stream as the data comes in

3.      It will try to match the events to triggers that have defined in your projects

Jenkins

• Jenkins is a Continuous Integration build system. Jenkins CI is a an extensible continuous integration engine. Jenkins is configured to work with Gerrit. 

• Every "Change" which is pushed to Gerrit is automatically picked up by Jenkins, built and smoke tested. 

• Jenkins is also setup with a 'regression' job which is designed to execute test scripts provided as part of the code change.

  

Basic Git Bash Commands

• Clone a repository :-- git clone --recursive repo_name/location

• Update from a remote repository:-- git submodule foreach "git pull --rebase"

• Commit to a local repository:-- git commit -a -m "commit message"

• push to a remote repository:-- git push

https://metacpan.org/pod/git-gerrit

Note: - Git Bash commands URL

http://www.codeproject.com/Articles/457305/Basic-Git-Command-Line-Reference-for-Windows-Users

This link is containing Gerrit Advanced Usage. http://www.mediawiki.org/wiki/Gerrit/Advanced_usage 

How to merge the changes with the latest updates?

First Process

In this workflow, you use merge when you need to update the topic branch with the latest changes in master.You follow the same process when you need to update your topic branch with changes made to this branch by another programmer:

• git checkout <topic branch>

• git fetch origin

• git merge origin/<topic branch>'''

When you are ready to push the changes for code review, you merge your topic branch in to master and use the --squash option to create one big commit.

1. git checkout master
2. git pull origin
3. git checkout -b <temp branch>
4. git merge --squash <topic branch>
5. git push origin HEAD:refs/for/master

Note that once the change has been submitted by the reviewer and merged in to master, you should stop using the old topic branch. New work should happen in a new topic branch created off the latest version of master.

Second Process:- 

always rebase on top of master

In this approach, whenever you need to update the topic branch with the latest changes in master, you follow the following steps.This takes the changes in the topic branch and applies them on top of master's HEAD.

1. git checkout <topic branch>
2. git fetch origin
3. git rebase -i origin/master
4. git push origin HEAD:refs/for/master

When you are ready to submit the topic branch for code review, you follow a similar process. You rebase the topic branch on master, then push the changes in the topic branch for code review. You can do an interactive rebase using the -i option, which will allow you to squash all the commits on the topic branch together in to one big commit.

Note: If you are following this workflow, it is important that you do not use merge to update the topic branch with the contents of master. If you do, and you later perform a rebase prior to submitting your changes for code review, you may find that you have to redo work you did in earlier merges. Specifically, you may have to manually resolve conflicts that you previously resolved.

 

Note:-

Please find some questions and answers corresponding to Git and Gerrit in this below link: -

http://gitenterprise.me/category/gerrit/