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?

Joachim Sauer
  • 10,956
  • 3
  • 52
  • 45
user1366476
  • 783
  • 1
  • 6
  • 5

1 Answers1

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.

Martin Atkins
  • 1,146
  • 8
  • 6
  • 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 05 '12 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 05 '14 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 05 '14 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 05 '14 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 05 '14 at 23:21
  • 2
    I don't agree that Gerrit makes commits larger. It just makes developer to publish nicer history. Instead of bunch of unpolished commits which may be even broken, gerrit forces to pay attention to each commit you are merging into a public branch. Makes git bisect nicer. I would say that Gerrit is for a enterprise, centralised projects, when everyone supports single source code base.While GitHub is more appropriate for open-source public projects when you could have multiple personal clones. – kan Jan 28 '16 at 17:37
  • 1
    Use Gerrit extensively, both internally and externally on OpenStack. Also worked with GitHub. Gerrit's workflow encourages correctness of individual commits, while the PR workflow, encourages top loading of fixes, which is easier to contribute, but ultimately painful when needing to port across multiple branches. Even if GitHub helps here, it means that you need an additional tool to handle a basic requirement for support. Be nicer if Gerrit provided the ability to also view diffs from a topic level, but for larger projects usefulness/correctness of individual commits wins for maintainability. – dbailey Oct 27 '16 at 10:47
  • on a followup to this : how would you involve Test folks at the end of each workflow? lets say you have to give a deliverable to test - would you mark it complete at your first PR or after all code review is done(possibly multiple PRs). (i know it is a process question but i just want to understand what others do) – Akshat Mar 22 '17 at 15:10