68

I am starting a software project that will be team AND community developed. I was previously sold on gerrit, but now Github's fork and pull request model seem to almost provide more tools, ways to visualize commits, and ease of use.

For someone who has at least a little experience with both, what are the pros/cons of each, and which would be better for a team based project which wants to leave open the possibility for community development?

Improve this question

1 Answer 1

Reset to default
91

The major difference between Gerrit's and GitHub's workflows are how changes are modeled.

In Gerrit, every commit is a change that stands on its own. Although Gerrit will show you the relationships between commits, reviews are performed on a per-commit basis. Teams that are good at breaking large changes down into small, self-contained commits are likely to have more success with Gerrit. However, since Gerrit's model includes successive revisions to a particular commit it encourages Git workflows that many developers are not accustomed to, such as amending an earlier commit and re-pushing it, or squashing a growing set of commits from a topic branch into a single commit.

In Github, a pull request models a relationship between two branches. The expected workflow on Github is to commit one or more changes into a topic branch (often in a fork of the repository, but not necessarily) and create a pull request between that branch and the "upstream" branch. In this case, what is being reviewed is a set of commits that continues to grow as the review continues. The result is a set of changes that can then be merged atomically when they are complete. Pull requests can be effective at tracking changes with a larger scope that may be implemented over multiple commits. Pull requests also support SCM workflows that more developers are accustomed to, such as responding to a review comment by submitting a follow-up commit in the same branch.

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.

Gerrit's advantage is a deeper relationship with Git. Github Pull Requests are far enough removed from Git's standard data model that one must use either Github's web UI or its proprietary API to create pull requests. Gerrit's interface for creating and updating changes is the git protocol itself.

Improve this answer
8
  • 8
    Thanks Martin, that's an interesting answer. I have been meaning to look at Gerrit for a while, but think I'll shelve that. If it encourages editing history and squashing commits I want nothing to do with it. *8'(
    – Mark Booth
    Nov 5, 2012 at 16:41
  • 18
    Just to be clear (I use Gerrit often at my workplace), what Martin says here, "Gerrit...encourages Git workflows...such as amending an earlier commit and re-pushing it, or squashing a growing set of commits...into a single commit" is exactly correct. My clarification is that @MarkBooth's comment about "editing history" isn't what Martin said. Amending commits (while still on Gerrit, and not yet merged to origin/master) does not involve "editing history". In fact, this workflow works great. The 'bad' editing of history Mark Booth refers to is re-pushing edited histories to origin/master.
    – likethesky
    Jan 5, 2014 at 22:04
  • 2
    Thanks for the clarification @likethesky but I have a rather more literal interpretation of 'editing history', and as far as I'm concerned, anything which results in changesets which contain content that you didn't explicitly commit is 'editing history'. I realise though that this is a rather draconian interpretation and one which few others adhere to. *8')
    – Mark Booth
    Jan 5, 2014 at 22:10
  • 2
    Fair enough. :-) Not sure I understand what you mean by "changesets which contain content you didn't explicitly commit," so pls. elaborate... I assume that you're not saying that you never ever commit temporary (local, or shared amongst team members via remote branches) commits like, "WIP: this attempts to solve the arch issue we discussed," followed by a more helpful squash/amend that says, "Issue 123: Refactored XYZ to increase resiliency and horizontal scaling ease" as a final commit message for that work. But anyway, of course you can choose to use git in any way that makes you happy!
    – likethesky
    Jan 5, 2014 at 22:28
  • 7
    This is a fantastic answer. To add, I've found that GitHub's pull requests foster smaller, more iterative commits and often ends up with a much more descriptive git log that shows not only the work product but the work process. Gerrit's code review fosters much cleaner repository history (there are very, very few actual merge commits) with larger, more polished commits.
    – tophyr
    Aug 5, 2014 at 23:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.