GitHub pull request model and Gerrit Code Review, which one is best for you ?
What are the plus and minuses of both models ?
See how it make sense to use one or the other or even both together.
The GitHub plugin for Gerrit Code Review allows the existing developers community to start exploring code review without loosing contact with the github.com presence.
2. 2 .io
About Luca
• Luca Milanesio
Co-founder of GerritForge
• over 20 years of experience
in Agile Development
SCM and ALM worldwide
• Contributor to Jenkins
since 2007 (and previously Hudson)
• Git SCM mentor
for the Enterprise since 2009
• Contributor to Gerrit Code Review community since 2011
4. 4 .io
Agenda
Fork+Pull request or Change review ?
People says …
My experience say …
Plugging two worlds together
echo "github" | sed -e "s/git/gerrit/"
Pull requests and Repo replication
What do YOU think ?
8. 8 .io
Two worlds at a glance
1. BRANCH
2. SCORE THE
BRANCH
3. MERGE ALL
COMMITs in
BRANCH
1. CHECKOUT
2. SCORE THE
COMMIT
3. MERGE ONLY the
REVIEWED
COMMIT
10. 10 .io
There are two fundamental problems with single-
patch review systems:
1. They encourage lumping at-best-weakly-related
changes together.
2. They encourage you to hide your history.
[http://bit.ly/1hhQkcA]
The pull-request system looks like an incredible
easy way to contribute to any project hosted on
Github [but] doing any proper and useful
contribution to a software is never done right the
first time.
But as a software maintainer you'll end up with
pull-request you'll never get finished unless you
wrap things up yourself.
[http://bit.ly/1o7HIb6]
A big advantage in Github's favor is the number of
developers that are familiar with it compared to
Gerrit.
Gerrit can be popular with Git power-users, but
friction-free use of it requires intermediate or
advanced git knowledge, and tolerance of a steep
learning curve.
[http://bit.ly/1cJV8IJ]
I have no problem with people using github as a
hosting site, but in order for *me* to pull from
github, you need to
(a) make a real pull request […]: real explanation,
proper email addresses, proper shortlog, and
proper diffstat.
(b) since github identities are random, I expect
the pull request to be a signed tag
[http://bit.ly/1iONQ4L]
12. 12 .io
Review model
DO NOT make git bisect + git cherry-pick useless
DO NOT throw commits over the fence
(e.g. “I’ve made the pull request, now it’s up to you”)
23. 23 .io
Step#1 - GitHub OAuth 2.0 application keys
https://github.com/settings/applications/new
Your server URL
(hostname / port Gerrit
will listen to)
OAuth 2.0 callback URL
is
Your server URL +
/oauth
24. 24 .io
Step#2 – Get OAuth Client-Id / CLient-Secret
GitHub OAuth 2.0 credentials for Gerrit
integration