Using git in eclipse by Chris Aniszczyk

Using Git in Eclipse
http://eclipse.org/egit

Chris Aniszczyk (Red Hat)
zx@redhat.com
http://aniszczyk.org

About Me
I've been using and hacking Eclipse for nearly a decade

Eclipse Board of Directors, Committer Representative

Member in the Eclipse Architecture Council

I like to run! (just finished Chicago marathon in 3:20)

Co-author of RCP Book (www.eclipsercp.org)

Using Git in Eclipse | © 2010 by C. Aniszczyk and M. Sohn

Outline
Git, EGit and JGit
Git Concepts
- Demo of EGit
Code Review at Eclipse
Gerrit
Conclusion


Software Trends and Revolution
Most major open source projects use some form of DVCS

Git, Hg, Bazaar

Linux
X.org
MySQL
OpenJDK
Android
JQuery
Gnome
Fedora
Bugzilla and so on...


Git
… a distributed revision control system built by the
Linux project to automate patch workflow

Distributed means no central repository
•No central authority!
•Easy offline usage
•Easy to fork a project
•Protected against manipulation by cryptographic hashes

Really good at merging
•Coordination only needed "after the fact”
•Easier to rejoin (or refresh) forked projects

Structured around commits (i.e. patches)
•Integrates with email channel
•Tools for identifying problem commits (git bisect)
•Tools for restructuring branches w/ specific commits


Projects using Git
… Git is widely used and is the most popular
distributed version control system


Git at Eclipse
Eclipse defined a roadmap to move to Git in 2009
CVS is deprecated; SVN will be deprecated in the future

EGit is an Eclipse Team provider for Git
http://www.eclipse.org/egit/

JGit is a lightweight Java library implementing Git
http://www.eclipse.org/jgit/

The goal is to build an Eclipse community around Git

EGit and JGit are still beta and we want to establish
a feedback loop to improve the tooling


Git at Eclipse
EGit and JGit developed at http://egit.eclipse.org

http://git.eclipse.org/
hosts live Eclipse Git repos
Virgo, Mylyn Review, ECF, SWTBot …

http://dev.eclipse.org/git/index.html
git mirrors for CVS
Read-only copies kept up-to-date
Can clone with git:// or http://


History of JGit and EGit
2005 Linus Torvalds starts Git

2006 Shawn Pearce starts JGit

2009 Eclipse decides for Git Roadmap
JGit/EGit move to eclipse.org
SAP joins JGit/EGit

3/2010 Released 0.7 (first release at Eclipse)
Diff/Merge Algorithms, Automatic IP Logs

6/2010 Released 0.8 (Helios)
Usability Improvements, Git Repositories View, Tagging

9/2010 Released 0.9 (Helios SR1)
Merge, Synchronize View, .gitignore

Planned: 12/2010 0.10 (Helios SR2) 3/2011 0.11 6/2011 1.0 (Indigo)


Features EGit 0.10
** planned for 0.10, * planned for 0.11
supported, partial, missing, irrelevant for EGit

git-add
git-add git-format-patch
git-format-patch git-shortlog
git-shortlog git-relink
git-relink git-rev-parse
git-rev-parse

git-am
git-am git-gc
git-gc git-show
git-show git-remote
git-remote git-show-branch
git-show-branch

git-archive
git-archive git-grep
git-grep git-stash
git-stash git-repack
git-repack git-verify-tag
git-verify-tag

git-bisect
git-bisect git-init
git-init git-status
git-status git-replace
git-replace git-whatchanged
git-whatchanged

git-branch
git-branch git-log
git-log git-submodule
git-submodule git-annotate
git-annotate

git-bundle
git-bundle * git-merge
* git-merge * git-tag
* git-tag * * git-blame
git-blame .gitignore
.gitignore

git-checkout
git-checkout git-mv
git-mv git-config
git-config git-cherry
git-cherry git daemon
git daemon

git-cherry-pick
git-cherry-pick git-notes
git-notes git-fast-export
git-fast-export git-count-objects
git-count-objects Visual merge tool
Visual merge tool

git-clean
git-clean git-pull
git-pull git-fast-import
git-fast-import git-difftool
git-difftool ** HTTP support
** HTTP support

git-clone
git-clone git-push
git-push git-filter-branch
git-filter-branch git-fsck
git-fsck * * Mylyn integration
Mylyn integration

git-commit
git-commit ** git-rebase
** git-rebase git-mergetool
git-mergetool git-get-tar-commit-id
git-get-tar-commit-id * * Staging View
Staging View

git-describe
git-describe git-reset
git-reset git-pack-refs
git-pack-refs git-help
git-help * * Synchronize View
Synchronize View

git-diff
git-diff git-revert
git-revert git-prune
git-prune git-merge-tree
git-merge-tree History View
History View

git-fetch
git-fetch git-rm
git-rm git-reflog
git-reflog git-rerere
git-rerere Repositories View
Repositories View

Learning Git – There's no free lunch!
… the purpose of this presentation isn't to teach you Git,
you have to do that yourself!


Git Resources
http://git-scm.com/documentation is your friend

Watch Linus' talk at Google
http://www.youtube.com/watch?v=4XpnKHJAok8

Read the Pro Git book - http://progit.org/book/


Outline
Git, EGit and JGit
Git Concepts
Code Review and Eclipse
Gerrit
Conclusion


Centralized VCS
Examples? CVS and SVN

There is one Master repository where code is shared

Everyone checks out their code (or branch) from that
repository, and checks changes back in

Two major problems
• You need to be on-line to perform actions
• Patches go stale

They are generally terrible, antiquated

Understanding and Using Git at Eclipse | © 2010 by C. Aniszczyk, S. Pearce, R. Rosenberg and M. Sohn

Distributed VCS
Examples? Git and Hg

Each user has a full local copy of the repository

Forks happen, deal with it

There is no real master repository like in a CVCS


How does it work?
A DVCS like Git generally operates at the level of a
changeset

Logically, a repository is made up from an initial empty
state, followed by many changesets

Changesets are identified by a SHA-1 hash value

e.g., 0878a8189e6a3ae1ded86d9e9c7cbe3f


It's all about the changesets

Changesets contain pointers to the previous changeset

previous: 48b2179994d494485b79504e8b5a6b23ce24a026
--- a/README.txt
+++ b/README.txt
@@ -1 +1 @@
-SVN is great
+Git is great

previous: 6ff60e964245816221414736d7e5fe6972246ead
--- a/README.txt
+++ b/README.txt
@@ -1 +1 @@
-Git is great
+SVN is great


Branches
The current version of your repository is simply a pointer
to the end of the tree

The default "trunk" in Git is called "master"

The tip of the current branch is called "HEAD"

Any branch can be referred to by its hash id

Creating branches in a DVCS is fast, you simply point to
a different element in the tree on disk already


Merging
DVCS are all about merging

Merges are just the weaving together of two (or more)
local branches into one

However, unlike CVCS, you don't have to specify
anything about where you're merging from and to; the
trees automatically know what their split point was in the
past, and can work it out from there.

Merging is much easier in a DVCS like Git


Pulling and Pushing
We've not talked about the distributed nature of DVCS

Changes flow between repositories by push and pull

Since a DVCS tree is merely a pointer to a branch...

There's three cases to consider for comparing two trees:
• Your tip is an ancestor of my tip
• My tip is an ancestor of your tip
• Neither of our tips are direct ancestors; however, we
both share a common ancestor


Cloning and Remotes
git clone git://egit.eclipse.org/egit.git

Where you can push or pull to is configured on a per
(local) repository basis

git remote add github http://github.com/zx/myegit.git

origin is the default remote; you can have many remotes


Demo: A tour of EGit


What is Peer Code Review? Guido van Rossum [1]

When one developer writes code, another developer
is asked to review that code

A careful line-by-line critique

Happens in a non-threatening context

Goal is cooperation, not fault-finding

Often an integral part of coding process

Debugging someone else's broken code
– Involuntary code review: Not so good; emotions may flare
[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf


Code Review – Benefits Guido van Rossum [1]

Four eyes catch more bugs
 Catch bugs early to save hours of debugging

Enforce coding standards
 Keep overall readability & code quality high

Mentoring of new developers
 Learn from mistakes without breaking stuff

Establish trust relationships
 Prepare for more delegation

Good alternative to pair programming
 asynchronous and across locations
[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf


Code Review at

Eclipse ?


Eclipse - Roles
Committer
Formally elected
Can commit own changes without review

Contributor
Small changes
reviewed by committers
Bigger changes
also formal IP review by legal team
in separate protected Bugzilla (IPZilla)

Review Tool
patches attached to bug in Bugzilla
comments in Bugzilla

Code Review via Bugzilla


Eclipse – Review Process
Contributors
• create patch using CVS, SVN, Git (since 2009)
• attach patch to bug in Bugzilla

Committers
• do code and IP review
• comment, vote in Bugzilla
• create CQ for changes needing IP review
• commit accepted changes

IP Team
• does IP review bigger changes from contributors


Eclipse – Review Process
Review not done for all changes

Each Eclipse.org project does it differently

Review tedious for contributors
(and also for committers mentoring contributors)


Outline
Git, EGit and Jgit
Git Concepts
Code Review and Eclipse
Gerrit
Conclusion


Gerrit Code Review

Gerrit is a Code Review system based on JGit
http://code.google.com/p/gerrit/

Also serves as a git server
adding access control and workflow

Used by
• Android https://review.source.android.com/
• JGit, EGit http://egit.eclipse.org/r/
• Google, SAP, …

Eclipse wants to use it …


History: Google and code review tools
Mondrian (Guido van Rossum)
• based on Perforce, Google infrastructure
• Google proprietary

Rietvield (Guido van Rossum)
• based on Subversion
• Open Source hosted on GoogleApp Engine

Gerrit (Shawn Pearce)
• started as a fork of Rietvield
• based on JGit and GWT
• Open Source (Android)
• Apache 2 license


One Branch per Feature
Master branch contains only reviewed and
approved changes
• master moves from good to better state after
each (approved) change

Each feature branch is based on the Master
branch
• stable starting point

A change can really be abandoned because
• no other approved change can depend on a not
yet approved change
• Gerrit will automatically reject a successor
change of an abandoned change


Gerrit – Lifecycle of a Change
•
create local topic
topic
branch
master
•
commit change
1 •
push it for review
a •
do review
•
automated
verification


•
create local topic
topic branch
master
•
commit change
•
push it for review
1 •
do review
•
automated
a
verification

topic master

c
•
refine based on
3 review
•
push new patchsets
b
2 until review votes ok

1 a


•
create local topic master
topic branch
master •
commit change
•
push it for review d
topic
1 •
do review
a
•
automated
verification c
3

b
topic master 2

c
•
refine based on a
1
3 review
•
push new patchsets
b until review votes ok
2
•
Submit may lead to
server-side merge
1 a •
or merge / rebase before
push

Gerrit Workflow


Code Review – Our Experience
Review all changes!

Review takes time (1 day … weeks)

Implies parallel workflow

Every team member should do reviews regularly

Authors have to wait for the review to happen

Git & Gerrit help a lot here

Code Review | © 2010 by M. Sohn

Conclusion
EGit and JGit are evolving quickly

Gerrit enables a nice code review workflow

Git supports convenient branching and merging

Git is very fast and scales well

Eclipse and major other OS projects are moving to Git

Open source has embraced the way of DVCS


Using git in eclipse by Chris Aniszczyk

Recomendados

Recomendados

Más contenido relacionado

Similar a Using git in eclipse by Chris Aniszczyk

Similar a Using git in eclipse by Chris Aniszczyk (20)

Más de EclipseDayParis

Más de EclipseDayParis (11)

Using git in eclipse by Chris Aniszczyk