Git and Gerrit: Walkthrough
Refer below wiki pages for the steps/installation of usage in FlexPLM.
1. http://rdwiki.ptcnet.ptc.com/mediawiki/index.php?title=Git_and_Gerrit_for_FlexPLM
2. http://rdwiki.ptcnet.ptc.com/mediawiki/index.php?title=GIT_Daily_Operations_-_FlexPLM
3. http://rdwiki.ptcnet.ptc.com/mediawiki/index.php?title=GIT_Code_Review_-_FlexPLM
Note: This document is a walkthrough to workflow of Git, Gerrit, the role of Jenkins CI and also lists
some basic git commands used in day today activities.
Git and Gerrit workflow
Git is distributed and open source version control system: every developer has the full history of
their code repository locally.
- Speed
- Offline working
- Secure (SHA1)
- Branching and Merging
Here is a basic overview of how Git works:
1. We have a git initialized "repository" or we clone the repository.
2. “fetch” or "pull" the latest changes to your local machine.
3. Create a "branch", make required changes in local repo and then “commit” the changes.
4. "push" your changes to your master branch.
[email protected] Page 1 of 11
Gerrit is a web based code review system developed for Git.
Mediator between Git repos & developers.
Note: Every commit we make is tracked because of setting name and email variables in git config
file.
How does Gerrit work? (Basic Flow)
1. Gerrit can prevent users from pushing directly to the Git repository.
2. If you push to Gerrit, you use a certain path (ref specification) which tells Gerrit that you want to
create a change.
3. Gerrit creates a new change or makes an update of an existing one.
4. A change consists of one or more patch sets.
5. Then we click on Submit to merge the changes to Remote master branch.
Just for Info: It is still possible to bypass code review by pushing directly to refs/heads/master if
sufficient rights have been granted.
[email protected] Page 2 of 11
▪ Remote In Git, the term remote is concerned with the remote repository
▪ origin is referred to the remote repository where you want to publish your commits.
▪ master is the default branch created when you initialized a git repository (e.g. git init).
- Git has two types of branches called local and remote. Your local repository has its master
branch that always up to date with the master of a remote repository.
o git pull origin master
o git push origin master
- refs/heads/master is a branch in your working copy named master. Frequently that is a
tracking branch of refs/remotes/origin/master because origin is the default name for
the remote created by git clone and its primary branch is usually also named master.
▪ HEAD is a pointer to the most recent commit of the branch you are currently on.
- You can delete the master branch (e.g. git branch -D master). But you cannot delete the
HEAD pointer.
- There can only be a single HEAD at any given time (excluding git work tree).
- The content of HEAD is stored inside .git/HEAD, and it contains the 40 bytes SHA-1 of the
current commit
- $ git show HEAD
▪ Git Index Is a staging area between the working directory and repository.
- There are three places in Git where file changes can reside, and these are working directory,
staging area, and the repository.
[email protected] Page 3 of 11
Gerrit code submission high level overview
How does Gerrit work? (Detailed)
1. Gerrit can prevent users from pushing directly to the Git repository.
2. If you push to Gerrit, you use a certain path (ref specification) which tells Gerrit that you want to
create a change. This push ref specification is refs/for/master if the target of the change under
review is the master branch.
3. Gerrit creates a new change or makes an update of an existing one. (commit-msg hook is
installed to automatically generate and insert a Change-Id during git commit)
4. Gerrit uses the Change-Id information in the commit message to identify if the push is a new
commit or an update of an existing change.
5. A change consists of one or more patch sets which are used to improve the first proposal based
on review comments. One patch set corresponds to one Git commit.
6. Just for Info: It is still possible to bypass code review by pushing directly to refs/heads/master if
sufficient rights have been granted.
Git basic commands
1. Basic commands
2. pull /fetch changes
3. commit and push changes
4. undo the local commit
5. git stash
6. checkout and cherry-pick
[email protected] Page 4 of 11
Git Commands
1. Basic commands
$ git init
To generate a new empty Git repository or to reinitialize an existing one.
To clone a directory into new directory. It means we get a replica of an existing repository.
$ git branch
To display all the branches
$ git branch branch123
$ git checkout branch123
$ git checkout -b branch123
To create and checkout a branch on local machine
$ git branch -d branch123
$ git status
To check the changes done to the files or directory.
$ git log
Git history is represented as a series of interrelated commits, this can list those commits
$ git show HEAD
The tip of the current branch
[email protected] Page 5 of 11
2. pull /fetch changes
$ git fetch
Git gathers any commits from the target branch that do not exist in your current branch and stores
them in your local repository. However, it does not merge them with your current branch.
This does not change any of your own local branches under refs/heads, and is safe to do without
changing your working copy.
$ git merge
Merge takes all the changes in one branch and merges them into another branch in one commit.
$ git pull
This does a git fetch followed by a git merge which means it gets the new commits from remote repos
and merges the new commits into local branch.
$ git pull –rebase
You can pull using rebase instead of merge.
Rebasing is an alternative to merging. So instead of creating a new commit that combines the two
branches, it moves the commits of one of the branches on top of the other.
(Image reference: https://hackernoon.com/git-merge-vs-rebase-whats-the-diff-76413c117333)
[email protected] Page 6 of 11
3. commit and push changes
commit: adding changes to the local repository
push: to transfer the last commit(s) to a remote server
$ git add
$ git commit -a -m "some message"
$ git commit
Enter commit message in vi editor
{int:12345} Message Description
Press Esc and then type :wq to save and exit.
# Alternatively, you can commit through Git GUI.
Note: A standard 'commit-msg' hook is provided by Gerrit, and can be installed in the local Git
repository to automatically generate and insert a Change-Id line during git commit
…
$ git push origin master:refs/for/master
$ git push origin branch123:refs/for/master
$ git push origin master:refs/drafts/master
To push changes to for private review before publishing them to all developers.
Click Publish button to convert the draft into a change review.
[email protected] Page 7 of 11
4. Undo the local commit
# undo the local commit
$ git reset HEAD~
This is the default mode and keeps the changes in your working tree but not on the index;
It undoes the commit and leaves the changes you committed unstaged (so they'll appear as "Changes
not staged for commit" in git status, so you'll need to add them again before committing).
$ git reset --soft HEAD~1
Remove the last commit from the current branch, but the file changes will stay in your working tree.
Also, the changes will stay on your index.
It is like git reset HEAD~ but leaves your existing changes staged.
Use this if you only want to add more changes to the previous commit, or change the commit
message.
$ git reset --hard HEAD~1
Reset your current branch and working directory to its state at HEAD^
You will lose all uncommitted changes in addition to the changes introduced in the last commit.
The changes won't stay in your working tree so doing a git status command will tell you that you don't
have any changes in your repository.
$ git reset --keep HEAD~1
It only resets the files which are different between the current HEAD and the given commit.
It aborts the reset if anyone of these files has uncommitted changes. It's basically acts as a safer
version of hard.
$ git revert HEAD
Git revert simply creates a new commit with the changes that are rolled back
Note: git reset erases your git history instead of making a new commit.
$ git clean -df
Remove untracked files from the working tree
[email protected] Page 8 of 11
5. git stash
# git stash command enables you to switch branches without committing the
current branch
$ git stash
To save your un-committed changes in a "stash". Note: this removes changes from working tree.
$ git stash save "spr_123 changes"
$ git stash list
$ git stash show
$ git stash pop
$ git stash pop stash@{5}
$ git stash drop
…
[email protected] Page 9 of 11
6. Checkout and Cherry-pick
$ git checkout
The git checkout command switches branches, commits or restores working tree files.
It fetches the latest changes; it does not merge those new changes but makes your working directory
reflect them.
checkout just takes HEAD to a commit you specify, thus making working directory exactly as it was at
that commit.
$ git cherry-pick
Cherry picking in Git means to choose a commit from one branch and apply it onto another.
Fetches the commit and plays it on top of the current local branch, thus creating an entirely new
commit which happens to have same changes as the one it fetched.
cherry-pick supports ranges so you can specify start and end commit instead of listing all the commits.
i.e. git cherry-pick ebe6942..905e279
a - b - c - d Master
\
e - f - g Feature
$ git checkout master
$ git cherry-pick f
a - b - c - d - f Master
\
e - f - g Feature
[email protected] Page 10 of 11
GIT MERGE CONFLICTS AND ITS RESOLUTION
$ git pull --rebase
$ git mergetool
RESOLVE THE MERGE CONFLICTS
$ git rebase --continue
User1 → REPO
User2 → REPO
1. User1 Changes in Main.jsp and does commit, push and submits to remote repo.
2. User2 Also changes in Main.jsp and done a local commit;
Tries to do push to remote server; will get an error
[rejected] failed to push some refs to <remote URL>
As it will suggest you to pull the repository first before the push
3. User2 does git pull –rebase it will show an error
merge conflict in Main.jsp
4. git mergetool
5. Resolve the conflict
6. git rebase –continue
7. Now the conflict has resolved, and the local repository is synchronized with a remote repository.
8. git commit –amend
9. git push
GERRIT PATH CONFLICT
The change cannot be merged due to a path conflict. Rebase the change and upload the rebased
commit for review.
This error is raised if another change was merged earlier which modified some file your change has
also modified.
So, you have submitted a change and was approved. But by the time it gets reviewed other commits
have altered the main repository which now cause a conflict. Gerrit is unable to automatically merge
your change into the repository, you will have to fix it and resubmit the change.
https://www.mediawiki.org/wiki/Gerrit/Troubleshooting#Gerrit_complains_that_%22Your_change_could_not
_be_merged_due_to_a_path_conflict%22
[email protected] Page 11 of 11
