15 ms·

Abandoning Gitflow and GitHub in favour of Gerrit

239 points by hankeypancake 11y ago

codemac 11y ago
Anyone know of a good hosted gerrit solution? One of the largest problems I've had getting gerrit adoption on smaller teams is that they can just pop up a private github team easily, whereas finding hosted gerrit solutions that actually make it easy to convert from other source control tooling has been very difficult.
- fishywang 11y ago
  try gerrithub
chadnickbok 11y ago
The process might seem more complex initially but think of it like this: If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing. In addition, the new GitHub code review tools address most (if not all) of the stated reasons for this switch. And in my opinion, GitHub's ease-of-use, alongside it being an incredible single point of reference, far outweigh any clunky other tools I've used (like Gerrit).
- TheSwordsman 11y ago
  > Annndddd we're done I stopped reading exactly there, I knew that something was amiss. We followed that workflow at my last job, it worked well.
- sickbeard 11y ago
  I've used gerrit and it's much better than github/bitbucket. My knock on gerrit is it requires one "very good" git person to be on the team however it makes it very easy to support a larger team and do cleaner code reviews.
  - joncrocks 11y ago
    https://xkcd.com/1597/ https://xkcd.com/1597/
    - ams6110 11y ago
      :) Exactly how everyone I know uses git.
- jedberg 11y ago
  Heh, I literally had the same quote in buffer and was coming to make the same comment. Clearly they don't know how GitHub works.
  - cname 11y ago
    Am I missing something? What the article describes seems to be the most common way people use GitHub with a git flow branching style. Is the contention just over the "would _have_ to" part? I think it's likely the author knows that GitHub doesn't _require_ this. And even if not, it doesn't seem pertinent. Doing a PR from a branch of [a clone of] the main repo would require basically the same steps.
- aeorgnoieang 11y ago
  Does the new GitHub code review tool handle rebased commits like Gerrit does via "patch sets"? That seems like it would be really useful.
  - xintron 11y ago
    I know they've talked about implement something similar. Since the Open letter to GitHub a lot have changed and I wouldn't be surprised to see GitHub support most of what Gerrit has (and more) in a near future.
- StavrosK 11y ago
  What's wrong about what he said? Which step can you omit?
  - kevinmgranger 11y ago
    It's not that any of those steps can be omitted, it's that those steps overall are not difficult or complex.
    - StavrosK 11y ago
      Sure, but the author literally says "pushing to a special branch might seem more complex, but consider X." Those steps are more complex than pushing to a special branch.
    - marssaxman 11y ago
      Just last night I decided not to bother submitting a (tiny, one-line) patch to an open-source project because I didn't feel like going through all that rigmarole. The steps may not seem difficult or complex but they are steps, and they are friction, and eliminating friction is generally a good thing.
  - stepanhruda 11y ago
    Forking the repo
  - arjie 11y ago
    It needs the context. I've quoted the whole thing below: > If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request. With Gerrit, you could clone the main repository, do your change and then push it directly to the same remote as you cloned it from. The objection would be that you can always push to a branch and issue a PR from there in GitHub too. Those steps are identical for both tools in a professional setting. There are reasons for Gerrit but this isn't one.
    - chadnickbok 10y ago
- _jb 11y ago
  This is not the only argument in this piece — I'd even argue that it's a minor one. It hardly makes sense to discredit the author and this article based on this GitHub misconception.
  - VLM 11y ago
    The free floating anxiety and dislike of the article is a symptom of an architectural/mgmt mistake in the article. OK so there's a new long complicated extremely labor intensive elaborate detailed process. "Surely there had to be a better alternative?" Yes, yes there is. Unfortunately there are many options. Now the correct answer would have been simplicate and add lightness. Agile manifesto "Individuals and interactions over processes and tools". Instead, they found an overwhelmingly clunky and complex (their words not mine) tool to automate the complexity, or at least temporarily abstract it away, or at the very least replace one pile of complexity with another (larger?) pile of complexity. Lets try a less controversial topic. Getting a pencil. All workplaces have different policies for office supplies. Order your own just like you buy your own clothes. Here's your annual office max gift certificate buy whatever you want. Here's a key to a supply closet. But here, we implemented a 15 page process involving teams of employees reviewing and documenting each individual request for a pencil in meetings. That's the bad news. The good news, is we replaced the original 15 page process with a 5 page process by installing an IBM mainframe, DB2, CICS, and writing a simple COBOL app that allows end users with newly installed 3270 terminals to request a pencil, and now we're better off than "ever before". Now most people would have handed out GCs, given out supply closet keys, or just trusted the employees, so you're going to get all kinds of semi-off topic blowback about how the COBOL program should have been the flavor of the month CRUD web JS framework, or instead of DB2 they really should have used nosql on the cloud so they can scale office supply request to all 100 employees not just a small team. But the real problem that everyone is squirming about is they're doin' it all wrong.
  - chadnickbok 10y ago
    My main point here is that on GitHub, making a pull request is super easy. There's even a cool pop-up if you visit the main page of a repo after pushing to a branch that asks if you'd like to make a pull request. Saying that this is somehow more complex than updating a single commit and learning a whole new tool doesn't change that if you want to convince me, you at least need to correctly identify what's going wrong. Perhaps if the author had specifically called out their perceived failings of the very latest GitHub pull request changes I'd have given the article more time. But unfortunately the justification given for switching was really shallow.
- therealmarv 11y ago
  I'm not a git expert but I've contributed to repos which refused to merge the github pull request to keep their history clean. I mean, seriously?! So I don't know what is better...
  - stepanhruda 11y ago
    Github just added a way to squash pull requests to a clean commit last week, so there's that
  - Touche 11y ago
    I've never understood why people think omitting a historical event keeps their "history clean".
    - jasonlotito 11y ago
      If you don't understand, then clearly you should investigate why as you cannot form an opinion on something you don't understand.
      - Touche 11y ago
        I have investigated, why are you assuming I have not?
        jasonlotito 11y ago
        Clearly not enough, because you don't understand. You literally said that. How can you pass a judgement on something you don't understand?
        Touche 11y ago
        Who said I'm passing judgment? I a lot of people prefer that workflow so I'm guessing there is some merit. I just don't understand it (I've never gotten an explanation that satisfies me).
- bradyholt 11y ago
  This is a pattern I've seen in teams to enforce review of code before it's merged. You can make the main repo read-only for most of the team and require PRs be submitted from their own forks. Then, someone with write access on main repo can review and merge the PR. I think this is overkill, personally, but just want to point out that maybe this team was employing this process, rather than them not knowing how to create PRs from a branch.
  - chadnickbok 10y ago
    Sure thing - but that's a more complicated flow brought on by something other than GitHub.
- jeremiep 11y ago
  I had the same impression reading the intro; I was done after reading about Agile and consultants. In every single instance I've seen these two combined, mediocrity followed. Even in the cases where they thought they had agility the results were still terrible and unproductive. Most of the time its people not understanding the tech they're trying to use and instead of spending the time to learn it they look for something they already know how to use or they'll pay someone to do the thinking for them which usually overlooks most of the company's context. I know I'm grossly generalizing but that's the trend I've seen so far. They'll bash on Git for not being enough like SVN, bash on GitHub/GitLab for not having the same workflow of the previous tool. But will happily pay $200 an hour for someone to tell them what to use/do even if they end up making terrible decisions.
  - sopooneo 11y ago
    A thought just come to my head... For a lot of dev departments at non-tech companies, might consistent mediocrity be an improvement? If management is used to disaster at every turn, and then they hire some consultants, and then things are just lousy all the time, might that not count as a legit win for the consultants?
    - jeremiep 11y ago
      That's what I meant by "overlooking the company's context". I think the case you describe is where consultants can be a net win, for the very reason you mentioned: dev departments at non-tech companies. These companies are usually happy with "its quirky but works" software since it gets the job done and allows them to focus on their core skills. There's nothing wrong in not having programming as your core expertise. What I was describing is my experience seeing consultants and Agile brought in at companies where software development is their main area of expertise.
- ssmoot 11y ago
  Github isn't exactly a utopia of UX. Yesterday I was looking for a way to refresh an old fork with upstream. I'm pretty sure there was a button for this at one point. I looked. Couldn't find it. So instead I had to: $ cd ~/src $ mkdir github $ cd github $ git clone myfork $ cd myfork $ git remote add up upstream $ git pull up master $ git push origin master Or something like that. I think I got lost somewhere along the way trying to checkout the upstream branch (is it "up/master" or "up master"? It depends) but it took 5-ish minutes. Github may be pretty-ish, but I tend to avoid them these days. They're expensive, and they remove useful features. Fool me once, shame on you, fool me twice can't get fooled again.
  - quicklyfrozen 11y ago
    You can create a PR from the upstream to your repo, then accept that PR. (I know, that's not immediately intuitive, but at least you can do it without pulling a local copy.)
    - yxlx 11y ago
      I tried that once but ended up with a merge-commit with my name on it in the history of my "fork". Is it possible to not end up with such merge-commits?
      - quicklyfrozen 10y ago
        I don't think so -- you'll need to do something like a git rebase, and there's no way to do that via the GitHub UI. I know many don't like the 'dirty' history, but I like knowing exactly how the updates made it into my repo.
  - xenophonf 11y ago
    It'd be nice if there were a way to automatically update a fork, including the issue tracker, wiki, releases, etc. The best I've come up with is a set of scripts that iterate over all branches of all forks, running `git checkout $branch; git merge --ff-only upstream/$branch; git push`: https://gist.github.com/xenophonf/9df09e47a8629bb789ffbb94c7d17e42 https://gist.github.com/xenophonf/9df09e47a8629bb789ffbb94c7... I suspect that I'm probably doing forks on GitHub wrong, or at least I'm trying to use them in ways not envisioned by GitHub. In some cases I want to maintain copies of a GitHub repository for archival purposes (e.g., I'm afraid that the developer or GitHub will revoke public access to the repo), while in other cases, I want to institute a kind of code review process prior to merging upstream commits (e.g., I'm afraid of upstream doing something malicious). I will occasionally create branches in my forks, fix something, and send pull requests upstream, but I never feel like I need to maintain those forks---I'll happily delete branches or delete and re-create forks as needed.
thesis 11y ago
We tried Gerrit. We ran as fast as possible away. It seemed to hate merge commits, and would hang up often. I'm not sure if it's changed at all, but I think the only option was to review every commit individually inside of a branch. It seemed to really be pushing us towards squashing a branch and pushing that up.
- TheSwordsman 11y ago
  > I'm not sure if it's changed at all, but I think the only option was to review every commit individually inside of a branch. It seemed to really be pushing us towards squashing a branch and pushing that up. The author mentions this as being a feature of Gerrit in the post.
- oluwie 11y ago
  Gerrit does favor rebasing over merging but that's hardly a reason to run away from it
  - hinkley 11y ago
    Rebasing is great for version history but is hell for collaborating on a feature. If anything is the Achilles' heel of Git (aside from the groundbreaking levels of inconsistency in the CLI) it's this. the moment someone creates a new version control system that has most of what Git does but fixes parallel histories, I'll switch. And I don't mean that the way people say "if Bush wins again I'm moving to Canada." I say that as someone who has administered CVS, SVN and Perforce repositories on behalf of my teammates but wants nothing to do with administering Git.
    - pnathan 11y ago
      consider mercurial. You may be pleasantly surprised. edit: spelling
    - zo1 11y ago
      Would you care to elaborate what you find wrong/bad about "parallel histories"? I'm curious.
ozim 11y ago
What I miss in article is for how long they are on it. Is author after peak of inflated expectations? I have used Gerrit in my previous team and it did not worked so well. Hanging vetos on -2 are not that nice when you have to push feature forward, like instead of blocking it someone else could just fix it, by the time you talked person who put -2 to change it to -1. But maybe with more mature team it would not be a problem.
- xintron 11y ago
  We've been using it since May 2015. Vetos work well for us. We push new releases every week and often there are dependencies between the reviews (front-end waiting for a vetoed back-end review) which results in them being a non-issue (discussions happen frequently and updates are coming in quickly).
- distances 11y ago
  I think there's something amiss in your development process if you feel you can merge changes that have -1. What's the point of a review in this case? There's always hurry, but skipping reviews (and often unit testing too) is a sure way to make sure you'll keep busy fire-fighting in the future.
- jasonlotito 11y ago
  We've been using Gerrit since 2011, and it's worked really well this entire time. It does require communication if you have different features in different patches, but frankly, it's light years ahead of anything GitHub still has to offer in terms of pure code reviewing capability.
websitescenes 11y ago
"If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request." You don't have to do this with Github. Just clone directly to your local machine. Also, you don't have to use git flow when using Github. I think git flow seems to be the real culprit of the symptoms you have identified.
- kowdermeister 11y ago
  Exactly. There's multiple way of working together with Git/Hub. Gitflow is not a bible, but a customization workflow that should be adopted to the team.
  - Laaw 11y ago
    There are far fewer reasons not to use Gitflow than you might initially think.
    - websitescenes 10y ago
      I personally don't have any issues with Gitflow but it seems the OP does.
- balls187 11y ago
  > You don't have to do this with Github. Just clone directly to your local machine. If you use this model, your local clone isn't "backedup" by github until the pullrequest is merged, correct? One reason I like my teammembers to have their own local fork, is so they can have github exist as a backup.
  - daigoba66 11y ago
    Team members can also work in their own private branches that are pushed to a single repository - that's usually sufficient as a "backup".
aeorgnoieang 11y ago
There's a Gerrit service that integrates with GitHub: - [Gerrit Code Review for GitHub](http://gerrithub.io/ http://gerrithub.io/)
- therealmarv 11y ago
  nice one. Would be great to know if somebody has experiences with it?!
- edgan 11y ago
  If only it was only code review. This is basically another GitHub git hosting service using gerrit, and it syncs to github for open source projects. I don't want a new hosting service, I just want a code review process on top of GitHub.
  - piotrkaminski 11y ago
    Try https://reviewable.io https://reviewable.io then. Just code review, runs on top of GitHub, no extra repos to manage. (Disclosure: I'm the founder.)
  - _yp 11y ago
    Try Phabricator (http://phabricator.org/ http://phabricator.org/), you can point it at a remote repository without hosting it.
  - aeorgnoieang 11y ago
    I'm confused. It syncs (some of) your repos and any PRs in them, so what else do you need to do with it besides code review instead of with GitHub?
ninjakeyboard 11y ago
I use gerrit daily. It's a good tool once you learn it but as an end user I find it has some usability issues. I would very much recommend it though for teams. You'd need someone to instill good code review culture in your team. It dictates the +1/+2 review flow so you have to adhere to that for it to be a natural fit.
simula67 11y ago
Nothing about what was wrong about gitflow. One small correction I would like to make to gitflow is that the default branch for developers should be 'master'. If you want to deploy another branch, use a 'production' branch. This means people don't have to manually change branches everytime they clone, that type of repetitive work should be outsourced to a computer ( your deployment scripts ). If you have full access to the repo and you are on github, atleast you can change the default branch ( which for a repo I contribute to, I don't ) Anyone know the need for a seperate 'develop' branch ?
- sytse 11y ago
  I fully agree with using master for development. I also think that the git flow process is over the top for most teams. I detailed how to adopt just the things you need in GitLab flow. "you lost track of the comments in the code and viewing what had actually changed since the last update became really hard" I don't understand why comments in the code would disappear. Line-comments on the code might disappear when lines are changed. We're adding a feature to GitLab where you can acknowledge line comments. And viewing changes is pretty easy as long as you don't rebase.
- bryanlarsen 11y ago
  Note that you can change the default branch in github: https://help.github.com/articles/setting-the-default-branch/ https://help.github.com/articles/setting-the-default-branch/
- davnicwil 11y ago
  > Anyone know the need for a seperate 'develop' branch The HEAD of master should always be production-ready code. It is your most-stable branch. It's necessary to have a less-stable, separate, develop branch where features, bugfixes, etc, that were developed off on their own sandboxed branches can be merged and integrated as part of a development phase. Even with the most disciplined testing of isolated feature branches, it's not known whether integrating different ones will always work, so it is not even guaranteed that the HEAD of develop will always be stable, let alone production-ready. Even if it is stable, it could not be production-ready for the simple reason that it so far only contains features X and Y, and the next release cannot go out without Z there too, where Z is not merged yet. As you point out, having master as the most stable branch appears to just be a convention, and it would be perfectly possible to branch a production branch from master and swap the roles at the start of the project too. I think the convention is like that so that one can immediately build and run the latest production code after cloning the repo, which in my opinion is nice. Besides, with the number of branch switches you do every day as part of normal development, it doesn't seem too horrible to have to do it once, to start working off of develop after you clone the repo - at the end of the day how often do you do that, and how annoying or arduous really is it?
loopbit 11y ago
I don't see anything in the article that goes against gitflow. Is it just me? They don't want to use Github for the code review and prefer to use Gerrit? Good for them, I don't either and actually prefer GitLab or BitBucket for git in general. But hey! thanks for the Gerrit introduction. But gitflow? I've been using the gitflow way of working for ~5 years (although not always the gitflow extension) and I don't see anything there that clashes with that way of working. You want to work on a feature, perfect: Branch from develop and work away. After you are done and before you merge with develop again, you push your feature to Gerrit and do the code review/changes. And then merge back to develop. Really, I don't see the issue between Gerrit and gitflow and still think that gitflow is a very sane way of working in a team, specially if you have people that are not used to work with [distributed] version control systems and you probably wouldn't believe how many developers are out there like that.
lucaspottersky 11y ago
One word for Gerrit: UGLY! :P
- fishywang 11y ago
  yes but there's polygerrit project to improve that.
- russelluresti 11y ago
  It is fairly ugly, but it also allows you to drop in your own css file. It's not a 100% solution, but you can go a fairly long way towards making it more usable.
Laaw 11y ago
Without fail, every single one of these "Git Flow sucks!" or "GitHub sucks!" posts has a fundamental misunderstanding about one or the other. An example of this is my own team, where we currently have a list of "release/*" branches in our GitHub, because "git flow doesn't deal very well with hotfixing a release". Fundamental misunderstandings.
ahoka 11y ago
+2
- atomic77 11y ago
  ... still waiting for someone to workflow+1
desireco42 11y ago
What I got from this article is idea to squash every pull req into a single commit. I think this is valuable idea.
- xori 11y ago
  I agree, which github now does for you https://github.com/blog/2141-squash-your-commits https://github.com/blog/2141-squash-your-commits
  - desireco42 11y ago
    thank you for pointing this out for me
- ionforce 11y ago
  It's such a naive idea to apply this to every PR unilaterally.
- cyphar 10y ago
  As someone who does a lot of git bisecting, this is a horrible idea. Only do it on a case-by-case basis. If it takes 5 commits to make 5 complete changes that implement something, keep them as 5 commits.
bkeroack 11y ago
"At the time we had consultants working with us to speed up the development process..." Mistake #1.
theseoafs 11y ago
> As soon as someone added changes to their pull request – either by rebasing in the new changes or making it as a new commit – you lost track of the comments in the code and viewing what had actually changed since the last update became really hard (almost impossible if the new push was rebased with the new changes). Why are they all rebasing in their PR branches if it obviously makes the PR unreadable?
Negative1 11y ago
This is way more complex to me than GitFlow with pull requests. As a matter of fact, if you use something like SourceTree for most of the initial steps it's a few mouse clicks. Also, try Gitlabs for your reviews; it's pretty good! The idea of a more in-depth review is intriguing (we all know this is something that can be improved), but _voting_ on a peer's code just seems like a bad idea. Vote too low, people get insulted and you breed discontent and mistrust. Too high and everyone stays happy until code quality drops. People will either use this as an opportunity to diminish other's, show off or suck up. Sad, but that's human nature. I know in-person code reviews aren't always possible but adding this disconnect just seems like a bad idea. Would love some honest feedback from people who have actually used it in medium-large scale production.
- clay_to_n 11y ago
  What appeals to me about the voting scale is that it's well-defined: a -2 means "don't merge yet", a 1 means "looks good to me but I'm not sure that it's ready to merge". More of an enum than a voting mechanism. It sounds like it removes the ambiguity of when you leave a few comments on a PR but aren't explicit about whether you think it should be merged or not.
- sytse 10y ago
  Voting at GitLab is mostly thumbs up for good code and leave line comments for bad code. We don't vote bad code down, downvoting is mostly for issues with feature requests that are controversial.
xori 11y ago
I don't really see what's different. Both github and gerrit have voting and you're still creating a pull request like in github. The only difference is that this pull request is restricted to a single commit. Not very flexible, I see a lot of churn of invalid pull requests with this design if they aren't allowed to grow into complete features..
- kiallmacinnes 11y ago
  > Not very flexible, I see a lot of churn of invalid pull requests with this design if they aren't allowed to grow into complete features.. Actually, Gerrit really encourages growing a patchset ("pull request") into a complete feature. It allows you update your change over and over, addressing review comments as they come in. Once done, you have a clean "Add support for use of XYZ by ABC" commit - and not a pile of half baked commits - I cringe when I see things like this: "Add framework for XYZ", "Define Config for XYZ", "Correct typos", "Add tests", "Rework XYZ to be standards compliant", "Correct typos", "Fix tests"
  - cyphar 10y ago
    > > Not very flexible, I see a lot of churn of invalid pull requests with this design if they aren't allowed to grow into complete features.. > Actually, Gerrit really encourages growing a patchset ("pull request") into a complete feature. It allows you update your change over and over, addressing review comments as they come in. > Once done, you have a clean "Add support for use of XYZ by ABC" commit - and not a pile of half baked commits - I cringe when I see things like this: "Add framework for XYZ", "Define Config for XYZ", "Correct typos", "Add tests", "Rework XYZ to be standards compliant", "Correct typos", "Fix tests" I don't like commits like that either. But almost all real pull requests require more than one commit (so future generations can bisect the repo properly without then needing to bisect patches as well). A nice pull request is something like this: server: add statistics monitoring framework server: component a: hook into statistics monitoring api: expose statistics monitoring integration: add tests for statistics Each commit works as intended and does exactly one thing. I tried to do something like this on Gerrit (was contributing to the TWRP recovery) and it was such a pain that I collapsed everything to one commit. That's not how things should be dealt with (I needed to improve the pattern decryption to support N*N patterns and it required a bunch of UI, internals and other changes that all got squashed together). I also didn't like the fact that anybody could overwrite your PR's commit with their own crap. Why is that a feature?
eridius 11y ago
I really want something that provides better code review than GitHub. The described code review features of Gerrit sound promising. But the article says you can't submit a series of commits for review as a unit, you only submit a single commit. Is that really true? That seems like a rather awful limitation of the system. Sometimes my changes work well as a single commit, but often, especially when doing more complicated things, it's much more preferable to use a handful of related commits, all of which should get reviewed and merged as a batch. Does Gerrit not support this?
- piotrkaminski 11y ago
  You might want to check out https://reviewable.io https://reviewable.io. It has most (if not all) of the goodness of Gerrit, but is trivial to set up (SaaS) and integrates smoothly with GitHub. Every PR becomes a review and gets automatically updated whenever you push to the branch. Disclosure: I'm the founder.
  - eridius 11y ago
    Wow, the described feature set sounds pretty good. I'll definitely look into this. However, I will say the demo is a bit odd. It's pretty much impossible to look at the code diff because there are comments everywhere. And the code diff appears to default to not actually showing a diff (the left and right diff bounds are both set to the latest version), which is especially confusing when it shows side-by-side since it's showing the same revision on both sides.
    - piotrkaminski 11y ago
      Sorry about the mess on the demo review -- since everybody gets write access to try things out, it tends to get messy over time. I just reset it now so it looks clean again, and should probably just stick the reset script in a cron job... It's really odd that you got a nil default diff range. I can't reproduce it with either anonymous or authenticated access. If you can, could you please open an issue with more details so I can debug? Thanks!
piotrkaminski 11y ago
The article isn't particularly well written or argued, but it does have a core of truth to it: serious code review in GitHub is painful. However jumping straight to Gerrit to solve that problem seems like overkill to me. Sure, you get a really powerful and extremely configurable code review system, but you have to retrain for a new (and honestly a little long in the tooth) UX and spend time administrating the system. A lighter-weight SaaS like https://review.ninja https://review.ninja, https://omniref.com https://omniref.com, or https://reviewable.io https://reviewable.io (disclosure: this one's mine) might be a more appropriate solution. Specifically to the article's points, Reviewable has a nice reviews dashboard and will show inter-commit diffs within a PR (whether you're rebasing/amending or not), hiding any files with no changes since you last looked. Its default review completion criterion is that all files have been marked as reviewed by at least one person and there are no unresolved discussions still going on, but you can customize this to your team by writing a snippet of code to run against the review's state, e.g. to implement LGTM approval or even a voting system. Reviewable will also update a status check on the PR so you can enforce review completion before merging if that works best for your situation. Best of all, because both systems integrate tightly with GitHub, there's no need to learn a new workflow or mess around with new git commands. Gerrit still has its place but I don't think it should be the tool of first resort. (Edit: added mention of Omniref.)
- eeZi 11y ago
  Just use Phabricator! It's the best code review system I've used so far. Many large open source projects and companies have adopted it. Someone neatly wrote up the main advantages: http://cramer.io/2014/05/03/on-pull-requests http://cramer.io/2014/05/03/on-pull-requests Phabricator's issue tracker is also an excellent choice over GitHub's simplistic issue tracker. Also, Gerrit isn't that hard and I've seen small teams get productive with it within a 1-2 weeks. No need to reinvent the wheel! By the way: I live in Europe and I haven't worked for one single company which would allow their developers to host proprietary source code with a third party SaaS provider.
  - piotrkaminski 11y ago
    Phabricator is nice, but it's more of a full-featured replacement for GitHub as a whole. Some people want to keep most of GitHub and just improve on the code review aspects. > By the way: I live in Europe and I haven't worked for one single company which would allow their developers to host proprietary source code with a third party SaaS provider. Fair enough, companies vary widely in their acceptance of SaaS -- though Reviewable has plenty of European customers too. But to clarify, neither Review Ninja nor Reviewable (not sure about Omniref) actually host code themselves: they just access it through GitHub APIs without storing it. You can also deploy Review Ninja (and soon Reviewable) on-premises, though of course that means you're on the hook for administrating the system again.
1_800_UNICORN 11y ago
Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA. The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. It's unrealistic to ask someone to code review multiple commits per feature, and if you tie in your CI it doesn't make any sense to run your build over and over again for a single feature either. The patchsets DO allow you to see the history of a code review if you have to make changes, but I'd much rather see that live in my git history rather than in Gerrit's history. It's a dirty solution to have to amend your commits to make changes. Nowhere does the author mention how painful it is if you finish a feature, are waiting for a code review, but have to start the next feature using the code you just wrote. Maybe I'm missing some magical feature in Gerrit that makes this easy, but if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle.
- oautholaf 11y ago
  That's funny, as someone who has used both github and gerrit for several years each, I completely disagree. I found the gerrit flow worked well. At the gerrit-based shop, we kept very good discipline of regular, small checkins. And yes, you can pipeline your checkins too. I found the gerrit flow also much easier to explain to new engineers. The github PR flow is much more full of sharp edges.
- djsumdog 11y ago
  I used Gerrit for over a year at one company and I have to agree. Every minor change required amending a commit and another review. It really breaks a lot of the git process. I also had to admin a Gerrit server once and the documentation (at the time at least) for setting up and running a Gerrit server was total shit. It was a painful process to say the least. Another project, which took many of my old team members, started using Gitlab instead and they loved it. The merge requests made a lot more sense. I'm currently at a new company that uses Gitlab and I have to agree. Both systems are pretty much suggestive. We could always +1 a code review ourselves if it had to get out that day, but it's best someone else did it and there was a record. Gitlab is a lot more lose. There's no official field for an approval, but you can put in a nice little thumbs up emoji in your comment, and you have the same audit trail. TL;DR +1 Gitlab (et al.) over Gerrit for sure
jessegreathouse 11y ago
Out of the frying pan and into the fire. I don't like Github but, from the sound of it, Gerrit is more complicated which is what I don't want.
brown9-2 11y ago
Gerrit is being used by many large open source projects, It should be worth noting that those large open source projects have very, very different needs than a small development team working on a product together. The open source project likely isn't doing weekly releases (which require some sort of manual QA process, in the source article). A large open source project has hundreds of contributors, where reviewer time is scarcer than contributor time (and the pool of people to approve and commit a change is much smaller than the contributor pool). I think the OP's real problems are that: - an increased release frequency requires them to do more QA - their time spent in code review seems to be a function of how often they are "releasing", not how often people are making changes If the difficulty of making a release increases as you increase your release rate, you might be doing "agile" in a poor way.
u801e 10y ago
> As soon as someone added changes to their pull request – either by rebasing in the new changes or making it as a new commit – you lost track of the comments in the code and viewing what had actually changed since the last update became really hard (almost impossible if the new push was rebased with the new changes). We use github at work with a feature branch workflow (as opposed to gitflow). We've adopted a system where pull request comments are addressed through the use of "fixup" commits. For example, when a pull request is submitted for a feature branch that contains 3 commits, and a comment is made regarding part of the change, the person who submitted the PR will add a commit that addresses the comment with a commit title of: >> fixup! Title of the commit to update >> >> An explanation of what this commit does and why >> ... This, incidently, is exactly what git commit --fixup <commit_ref> does. Then the person responds to the comment saying that it was addressed in <commit_sha1>. As a reviewer, it makes it easy to see that my comment has been addressed and exactly what change was made to address it (by clicking on the link that github autogenerates from the sha1 in the comment). Once the review process is complete, the person will run git fetch origin and then git rebase -i --autosquash --keep-empty origin/master to actually reduce the set of commits down to the original clean set of commits. They then run a git diff <original branch head sha1>.. to verify that there are no differences and then they merge the PR using the merge button in the web interface. This way, you end up merging a clean set of commits for each PR, and it's still relatively easy to keep track of comments and incremental code changes addressing those comments during the PR. In fact, multiple developers can collaborate using the same branch by pushing up "fixup!" commits. Though they need to make sure that they fetch/merge or pull before they push to avoid unwanted merge commits within the branch.
ngrilly 10y ago
Exactly why I'm frustrated with GitHub's PR: > As soon as someone added changes to their pull request – either by rebasing in the new changes or making it as a new commit – you lost track of the comments in the code and viewing what had actually changed since the last update became really hard
dpc_pw 10y ago
I would never ever recommend gerrit to anyone.
killface 10y ago
Blech. I have to use Gerrit at one of my current clients, and I fucking hate it. Github's workflow is easy. You have a repo, you can fork it or create a feature branch, you can add multiple commits, and then open a PR. That makes sense. And the interface is pretty. In Gerrit, I still do commit-as-you-go, because that's the entire fucking point of Git. If I wanted SVN semantics in my repo, I'd use SVN. Then, we have to squash all the commits (I'm very anti-history-revision, but I know that's an opinion) and push up to a different origin. And god forbid if you want to work from that code point in a new branch while you wait for a review. Oh, and if you want to fix some issues found in review? Yeah, let's edit the history again... Oh, and there's a change id created that causes all kinds of other headaches. I have tools to manage and make sense of my git history. I absolutely hate things that force me to modify history. It might as well be voodoo magic when stuff goes wrong. It's often easier to blow it all away and start over. I do like the things it can help you enforce -- a good build and +1/+2 code review etc. But that's not enough to deal with all the little annoyances in gerrit. Especially since it's available in a much better tool -- gitlab. Gitlab is what comes after github has run its course for your team. It's got the same predictable and useful feel, it integrates great with CI tools, and it allows a similar GHPR-style way of merging. There's also BitBucket Server and other stuff.. but Gitlab has my vote in the strongest way possible.

239 points by hankeypancake 11y ago

Anyone know of a good hosted gerrit solution? One of the largest problems I've had getting gerrit adoption on smaller teams is that they can just pop up a private github team easily, whereas finding hosted gerrit solutions that actually make it easy to convert from other source control tooling has been very difficult.

fishywang 11y ago
try gerrithub

chadnickbok 11y ago

The process might seem more complex initially but think of it like this: If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing. In addition, the new GitHub code review tools address most (if not all) of the stated reasons for this switch. And in my opinion, GitHub's ease-of-use, alongside it being an incredible single point of reference, far outweigh any clunky other tools I've used (like Gerrit).

TheSwordsman 11y ago
> Annndddd we're done I stopped reading exactly there, I knew that something was amiss. We followed that workflow at my last job, it worked well.
sickbeard 11y ago
I've used gerrit and it's much better than github/bitbucket. My knock on gerrit is it requires one "very good" git person to be on the team however it makes it very easy to support a larger team and do cleaner code reviews.
- joncrocks 11y ago
  https://xkcd.com/1597/ https://xkcd.com/1597/
  - ams6110 11y ago
    :) Exactly how everyone I know uses git.
jedberg 11y ago
Heh, I literally had the same quote in buffer and was coming to make the same comment. Clearly they don't know how GitHub works.
- cname 11y ago
  Am I missing something? What the article describes seems to be the most common way people use GitHub with a git flow branching style. Is the contention just over the "would _have_ to" part? I think it's likely the author knows that GitHub doesn't _require_ this. And even if not, it doesn't seem pertinent. Doing a PR from a branch of [a clone of] the main repo would require basically the same steps.
aeorgnoieang 11y ago
Does the new GitHub code review tool handle rebased commits like Gerrit does via "patch sets"? That seems like it would be really useful.
- xintron 11y ago
  I know they've talked about implement something similar. Since the Open letter to GitHub a lot have changed and I wouldn't be surprised to see GitHub support most of what Gerrit has (and more) in a near future.
StavrosK 11y ago
What's wrong about what he said? Which step can you omit?
- kevinmgranger 11y ago
  It's not that any of those steps can be omitted, it's that those steps overall are not difficult or complex.
  - StavrosK 11y ago
    Sure, but the author literally says "pushing to a special branch might seem more complex, but consider X." Those steps are more complex than pushing to a special branch.
  - marssaxman 11y ago
    Just last night I decided not to bother submitting a (tiny, one-line) patch to an open-source project because I didn't feel like going through all that rigmarole. The steps may not seem difficult or complex but they are steps, and they are friction, and eliminating friction is generally a good thing.
- stepanhruda 11y ago
  Forking the repo
- arjie 11y ago
  It needs the context. I've quoted the whole thing below: > If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request. With Gerrit, you could clone the main repository, do your change and then push it directly to the same remote as you cloned it from. The objection would be that you can always push to a branch and issue a PR from there in GitHub too. Those steps are identical for both tools in a professional setting. There are reasons for Gerrit but this isn't one.
  - chadnickbok 10y ago
_jb 11y ago
This is not the only argument in this piece — I'd even argue that it's a minor one. It hardly makes sense to discredit the author and this article based on this GitHub misconception.
- VLM 11y ago
  The free floating anxiety and dislike of the article is a symptom of an architectural/mgmt mistake in the article. OK so there's a new long complicated extremely labor intensive elaborate detailed process. "Surely there had to be a better alternative?" Yes, yes there is. Unfortunately there are many options. Now the correct answer would have been simplicate and add lightness. Agile manifesto "Individuals and interactions over processes and tools". Instead, they found an overwhelmingly clunky and complex (their words not mine) tool to automate the complexity, or at least temporarily abstract it away, or at the very least replace one pile of complexity with another (larger?) pile of complexity. Lets try a less controversial topic. Getting a pencil. All workplaces have different policies for office supplies. Order your own just like you buy your own clothes. Here's your annual office max gift certificate buy whatever you want. Here's a key to a supply closet. But here, we implemented a 15 page process involving teams of employees reviewing and documenting each individual request for a pencil in meetings. That's the bad news. The good news, is we replaced the original 15 page process with a 5 page process by installing an IBM mainframe, DB2, CICS, and writing a simple COBOL app that allows end users with newly installed 3270 terminals to request a pencil, and now we're better off than "ever before". Now most people would have handed out GCs, given out supply closet keys, or just trusted the employees, so you're going to get all kinds of semi-off topic blowback about how the COBOL program should have been the flavor of the month CRUD web JS framework, or instead of DB2 they really should have used nosql on the cloud so they can scale office supply request to all 100 employees not just a small team. But the real problem that everyone is squirming about is they're doin' it all wrong.
- chadnickbok 10y ago
  My main point here is that on GitHub, making a pull request is super easy. There's even a cool pop-up if you visit the main page of a repo after pushing to a branch that asks if you'd like to make a pull request. Saying that this is somehow more complex than updating a single commit and learning a whole new tool doesn't change that if you want to convince me, you at least need to correctly identify what's going wrong. Perhaps if the author had specifically called out their perceived failings of the very latest GitHub pull request changes I'd have given the article more time. But unfortunately the justification given for switching was really shallow.
therealmarv 11y ago
I'm not a git expert but I've contributed to repos which refused to merge the github pull request to keep their history clean. I mean, seriously?! So I don't know what is better...
- stepanhruda 11y ago
  Github just added a way to squash pull requests to a clean commit last week, so there's that
- Touche 11y ago
  I've never understood why people think omitting a historical event keeps their "history clean".
  - jasonlotito 11y ago
    If you don't understand, then clearly you should investigate why as you cannot form an opinion on something you don't understand.
    - Touche 11y ago
      I have investigated, why are you assuming I have not?
      - jasonlotito 11y ago
        Clearly not enough, because you don't understand. You literally said that. How can you pass a judgement on something you don't understand?
        Touche 11y ago
        Who said I'm passing judgment? I a lot of people prefer that workflow so I'm guessing there is some merit. I just don't understand it (I've never gotten an explanation that satisfies me).
bradyholt 11y ago
This is a pattern I've seen in teams to enforce review of code before it's merged. You can make the main repo read-only for most of the team and require PRs be submitted from their own forks. Then, someone with write access on main repo can review and merge the PR. I think this is overkill, personally, but just want to point out that maybe this team was employing this process, rather than them not knowing how to create PRs from a branch.
- chadnickbok 10y ago
  Sure thing - but that's a more complicated flow brought on by something other than GitHub.
jeremiep 11y ago
I had the same impression reading the intro; I was done after reading about Agile and consultants. In every single instance I've seen these two combined, mediocrity followed. Even in the cases where they thought they had agility the results were still terrible and unproductive. Most of the time its people not understanding the tech they're trying to use and instead of spending the time to learn it they look for something they already know how to use or they'll pay someone to do the thinking for them which usually overlooks most of the company's context. I know I'm grossly generalizing but that's the trend I've seen so far. They'll bash on Git for not being enough like SVN, bash on GitHub/GitLab for not having the same workflow of the previous tool. But will happily pay $200 an hour for someone to tell them what to use/do even if they end up making terrible decisions.
- sopooneo 11y ago
  A thought just come to my head... For a lot of dev departments at non-tech companies, might consistent mediocrity be an improvement? If management is used to disaster at every turn, and then they hire some consultants, and then things are just lousy all the time, might that not count as a legit win for the consultants?
  - jeremiep 11y ago
    That's what I meant by "overlooking the company's context". I think the case you describe is where consultants can be a net win, for the very reason you mentioned: dev departments at non-tech companies. These companies are usually happy with "its quirky but works" software since it gets the job done and allows them to focus on their core skills. There's nothing wrong in not having programming as your core expertise. What I was describing is my experience seeing consultants and Agile brought in at companies where software development is their main area of expertise.
ssmoot 11y ago
Github isn't exactly a utopia of UX. Yesterday I was looking for a way to refresh an old fork with upstream. I'm pretty sure there was a button for this at one point. I looked. Couldn't find it. So instead I had to: $ cd ~/src $ mkdir github $ cd github $ git clone myfork $ cd myfork $ git remote add up upstream $ git pull up master $ git push origin master Or something like that. I think I got lost somewhere along the way trying to checkout the upstream branch (is it "up/master" or "up master"? It depends) but it took 5-ish minutes. Github may be pretty-ish, but I tend to avoid them these days. They're expensive, and they remove useful features. Fool me once, shame on you, fool me twice can't get fooled again.
- quicklyfrozen 11y ago
  You can create a PR from the upstream to your repo, then accept that PR. (I know, that's not immediately intuitive, but at least you can do it without pulling a local copy.)
  - yxlx 11y ago
    I tried that once but ended up with a merge-commit with my name on it in the history of my "fork". Is it possible to not end up with such merge-commits?
    - quicklyfrozen 10y ago
      I don't think so -- you'll need to do something like a git rebase, and there's no way to do that via the GitHub UI. I know many don't like the 'dirty' history, but I like knowing exactly how the updates made it into my repo.
- xenophonf 11y ago
  It'd be nice if there were a way to automatically update a fork, including the issue tracker, wiki, releases, etc. The best I've come up with is a set of scripts that iterate over all branches of all forks, running `git checkout $branch; git merge --ff-only upstream/$branch; git push`: https://gist.github.com/xenophonf/9df09e47a8629bb789ffbb94c7d17e42 https://gist.github.com/xenophonf/9df09e47a8629bb789ffbb94c7... I suspect that I'm probably doing forks on GitHub wrong, or at least I'm trying to use them in ways not envisioned by GitHub. In some cases I want to maintain copies of a GitHub repository for archival purposes (e.g., I'm afraid that the developer or GitHub will revoke public access to the repo), while in other cases, I want to institute a kind of code review process prior to merging upstream commits (e.g., I'm afraid of upstream doing something malicious). I will occasionally create branches in my forks, fix something, and send pull requests upstream, but I never feel like I need to maintain those forks---I'll happily delete branches or delete and re-create forks as needed.

thesis 11y ago

We tried Gerrit. We ran as fast as possible away. It seemed to hate merge commits, and would hang up often. I'm not sure if it's changed at all, but I think the only option was to review every commit individually inside of a branch. It seemed to really be pushing us towards squashing a branch and pushing that up.

TheSwordsman 11y ago
> I'm not sure if it's changed at all, but I think the only option was to review every commit individually inside of a branch. It seemed to really be pushing us towards squashing a branch and pushing that up. The author mentions this as being a feature of Gerrit in the post.
oluwie 11y ago
Gerrit does favor rebasing over merging but that's hardly a reason to run away from it
- hinkley 11y ago
  Rebasing is great for version history but is hell for collaborating on a feature. If anything is the Achilles' heel of Git (aside from the groundbreaking levels of inconsistency in the CLI) it's this. the moment someone creates a new version control system that has most of what Git does but fixes parallel histories, I'll switch. And I don't mean that the way people say "if Bush wins again I'm moving to Canada." I say that as someone who has administered CVS, SVN and Perforce repositories on behalf of my teammates but wants nothing to do with administering Git.
  - pnathan 11y ago
    consider mercurial. You may be pleasantly surprised. edit: spelling
  - zo1 11y ago
    Would you care to elaborate what you find wrong/bad about "parallel histories"? I'm curious.

ozim 11y ago

What I miss in article is for how long they are on it. Is author after peak of inflated expectations? I have used Gerrit in my previous team and it did not worked so well. Hanging vetos on -2 are not that nice when you have to push feature forward, like instead of blocking it someone else could just fix it, by the time you talked person who put -2 to change it to -1. But maybe with more mature team it would not be a problem.

xintron 11y ago
We've been using it since May 2015. Vetos work well for us. We push new releases every week and often there are dependencies between the reviews (front-end waiting for a vetoed back-end review) which results in them being a non-issue (discussions happen frequently and updates are coming in quickly).
distances 11y ago
I think there's something amiss in your development process if you feel you can merge changes that have -1. What's the point of a review in this case? There's always hurry, but skipping reviews (and often unit testing too) is a sure way to make sure you'll keep busy fire-fighting in the future.
jasonlotito 11y ago
We've been using Gerrit since 2011, and it's worked really well this entire time. It does require communication if you have different features in different patches, but frankly, it's light years ahead of anything GitHub still has to offer in terms of pure code reviewing capability.

websitescenes 11y ago

"If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request." You don't have to do this with Github. Just clone directly to your local machine. Also, you don't have to use git flow when using Github. I think git flow seems to be the real culprit of the symptoms you have identified.

kowdermeister 11y ago
Exactly. There's multiple way of working together with Git/Hub. Gitflow is not a bible, but a customization workflow that should be adopted to the team.
- Laaw 11y ago
  There are far fewer reasons not to use Gitflow than you might initially think.
  - websitescenes 10y ago
    I personally don't have any issues with Gitflow but it seems the OP does.
balls187 11y ago
> You don't have to do this with Github. Just clone directly to your local machine. If you use this model, your local clone isn't "backedup" by github until the pullrequest is merged, correct? One reason I like my teammembers to have their own local fork, is so they can have github exist as a backup.
- daigoba66 11y ago
  Team members can also work in their own private branches that are pushed to a single repository - that's usually sufficient as a "backup".

aeorgnoieang 11y ago

There's a Gerrit service that integrates with GitHub: - [Gerrit Code Review for GitHub](http://gerrithub.io/ http://gerrithub.io/)

therealmarv 11y ago
nice one. Would be great to know if somebody has experiences with it?!
edgan 11y ago
If only it was only code review. This is basically another GitHub git hosting service using gerrit, and it syncs to github for open source projects. I don't want a new hosting service, I just want a code review process on top of GitHub.
- piotrkaminski 11y ago
  Try https://reviewable.io https://reviewable.io then. Just code review, runs on top of GitHub, no extra repos to manage. (Disclosure: I'm the founder.)
- _yp 11y ago
  Try Phabricator (http://phabricator.org/ http://phabricator.org/), you can point it at a remote repository without hosting it.
- aeorgnoieang 11y ago
  I'm confused. It syncs (some of) your repos and any PRs in them, so what else do you need to do with it besides code review instead of with GitHub?

ninjakeyboard 11y ago

I use gerrit daily. It's a good tool once you learn it but as an end user I find it has some usability issues. I would very much recommend it though for teams. You'd need someone to instill good code review culture in your team. It dictates the +1/+2 review flow so you have to adhere to that for it to be a natural fit.

simula67 11y ago

Nothing about what was wrong about gitflow. One small correction I would like to make to gitflow is that the default branch for developers should be 'master'. If you want to deploy another branch, use a 'production' branch. This means people don't have to manually change branches everytime they clone, that type of repetitive work should be outsourced to a computer ( your deployment scripts ). If you have full access to the repo and you are on github, atleast you can change the default branch ( which for a repo I contribute to, I don't ) Anyone know the need for a seperate 'develop' branch ?

sytse 11y ago
I fully agree with using master for development. I also think that the git flow process is over the top for most teams. I detailed how to adopt just the things you need in GitLab flow. "you lost track of the comments in the code and viewing what had actually changed since the last update became really hard" I don't understand why comments in the code would disappear. Line-comments on the code might disappear when lines are changed. We're adding a feature to GitLab where you can acknowledge line comments. And viewing changes is pretty easy as long as you don't rebase.
bryanlarsen 11y ago
Note that you can change the default branch in github: https://help.github.com/articles/setting-the-default-branch/ https://help.github.com/articles/setting-the-default-branch/
davnicwil 11y ago
> Anyone know the need for a seperate 'develop' branch The HEAD of master should always be production-ready code. It is your most-stable branch. It's necessary to have a less-stable, separate, develop branch where features, bugfixes, etc, that were developed off on their own sandboxed branches can be merged and integrated as part of a development phase. Even with the most disciplined testing of isolated feature branches, it's not known whether integrating different ones will always work, so it is not even guaranteed that the HEAD of develop will always be stable, let alone production-ready. Even if it is stable, it could not be production-ready for the simple reason that it so far only contains features X and Y, and the next release cannot go out without Z there too, where Z is not merged yet. As you point out, having master as the most stable branch appears to just be a convention, and it would be perfectly possible to branch a production branch from master and swap the roles at the start of the project too. I think the convention is like that so that one can immediately build and run the latest production code after cloning the repo, which in my opinion is nice. Besides, with the number of branch switches you do every day as part of normal development, it doesn't seem too horrible to have to do it once, to start working off of develop after you clone the repo - at the end of the day how often do you do that, and how annoying or arduous really is it?

loopbit 11y ago

I don't see anything in the article that goes against gitflow. Is it just me? They don't want to use Github for the code review and prefer to use Gerrit? Good for them, I don't either and actually prefer GitLab or BitBucket for git in general. But hey! thanks for the Gerrit introduction. But gitflow? I've been using the gitflow way of working for ~5 years (although not always the gitflow extension) and I don't see anything there that clashes with that way of working. You want to work on a feature, perfect: Branch from develop and work away. After you are done and before you merge with develop again, you push your feature to Gerrit and do the code review/changes. And then merge back to develop. Really, I don't see the issue between Gerrit and gitflow and still think that gitflow is a very sane way of working in a team, specially if you have people that are not used to work with [distributed] version control systems and you probably wouldn't believe how many developers are out there like that.

lucaspottersky 11y ago

One word for Gerrit: UGLY! :P

fishywang 11y ago
yes but there's polygerrit project to improve that.
russelluresti 11y ago
It is fairly ugly, but it also allows you to drop in your own css file. It's not a 100% solution, but you can go a fairly long way towards making it more usable.

Laaw 11y ago

Without fail, every single one of these "Git Flow sucks!" or "GitHub sucks!" posts has a fundamental misunderstanding about one or the other. An example of this is my own team, where we currently have a list of "release/*" branches in our GitHub, because "git flow doesn't deal very well with hotfixing a release". Fundamental misunderstandings.

ahoka 11y ago

atomic77 11y ago
... still waiting for someone to workflow+1

desireco42 11y ago

What I got from this article is idea to squash every pull req into a single commit. I think this is valuable idea.

xori 11y ago
I agree, which github now does for you https://github.com/blog/2141-squash-your-commits https://github.com/blog/2141-squash-your-commits
- desireco42 11y ago
  thank you for pointing this out for me
ionforce 11y ago
It's such a naive idea to apply this to every PR unilaterally.
cyphar 10y ago
As someone who does a lot of git bisecting, this is a horrible idea. Only do it on a case-by-case basis. If it takes 5 commits to make 5 complete changes that implement something, keep them as 5 commits.

bkeroack 11y ago

"At the time we had consultants working with us to speed up the development process..." Mistake #1.

theseoafs 11y ago

Negative1 11y ago

This is way more complex to me than GitFlow with pull requests. As a matter of fact, if you use something like SourceTree for most of the initial steps it's a few mouse clicks. Also, try Gitlabs for your reviews; it's pretty good! The idea of a more in-depth review is intriguing (we all know this is something that can be improved), but _voting_ on a peer's code just seems like a bad idea. Vote too low, people get insulted and you breed discontent and mistrust. Too high and everyone stays happy until code quality drops. People will either use this as an opportunity to diminish other's, show off or suck up. Sad, but that's human nature. I know in-person code reviews aren't always possible but adding this disconnect just seems like a bad idea. Would love some honest feedback from people who have actually used it in medium-large scale production.

clay_to_n 11y ago
What appeals to me about the voting scale is that it's well-defined: a -2 means "don't merge yet", a 1 means "looks good to me but I'm not sure that it's ready to merge". More of an enum than a voting mechanism. It sounds like it removes the ambiguity of when you leave a few comments on a PR but aren't explicit about whether you think it should be merged or not.
sytse 10y ago
Voting at GitLab is mostly thumbs up for good code and leave line comments for bad code. We don't vote bad code down, downvoting is mostly for issues with feature requests that are controversial.

xori 11y ago

I don't really see what's different. Both github and gerrit have voting and you're still creating a pull request like in github. The only difference is that this pull request is restricted to a single commit. Not very flexible, I see a lot of churn of invalid pull requests with this design if they aren't allowed to grow into complete features..

kiallmacinnes 11y ago
> Not very flexible, I see a lot of churn of invalid pull requests with this design if they aren't allowed to grow into complete features.. Actually, Gerrit really encourages growing a patchset ("pull request") into a complete feature. It allows you update your change over and over, addressing review comments as they come in. Once done, you have a clean "Add support for use of XYZ by ABC" commit - and not a pile of half baked commits - I cringe when I see things like this: "Add framework for XYZ", "Define Config for XYZ", "Correct typos", "Add tests", "Rework XYZ to be standards compliant", "Correct typos", "Fix tests"
- cyphar 10y ago
  > > Not very flexible, I see a lot of churn of invalid pull requests with this design if they aren't allowed to grow into complete features.. > Actually, Gerrit really encourages growing a patchset ("pull request") into a complete feature. It allows you update your change over and over, addressing review comments as they come in. > Once done, you have a clean "Add support for use of XYZ by ABC" commit - and not a pile of half baked commits - I cringe when I see things like this: "Add framework for XYZ", "Define Config for XYZ", "Correct typos", "Add tests", "Rework XYZ to be standards compliant", "Correct typos", "Fix tests" I don't like commits like that either. But almost all real pull requests require more than one commit (so future generations can bisect the repo properly without then needing to bisect patches as well). A nice pull request is something like this: server: add statistics monitoring framework server: component a: hook into statistics monitoring api: expose statistics monitoring integration: add tests for statistics Each commit works as intended and does exactly one thing. I tried to do something like this on Gerrit (was contributing to the TWRP recovery) and it was such a pain that I collapsed everything to one commit. That's not how things should be dealt with (I needed to improve the pattern decryption to support N*N patterns and it required a bunch of UI, internals and other changes that all got squashed together). I also didn't like the fact that anybody could overwrite your PR's commit with their own crap. Why is that a feature?

eridius 11y ago

I really want something that provides better code review than GitHub. The described code review features of Gerrit sound promising. But the article says you can't submit a series of commits for review as a unit, you only submit a single commit. Is that really true? That seems like a rather awful limitation of the system. Sometimes my changes work well as a single commit, but often, especially when doing more complicated things, it's much more preferable to use a handful of related commits, all of which should get reviewed and merged as a batch. Does Gerrit not support this?

piotrkaminski 11y ago
You might want to check out https://reviewable.io https://reviewable.io. It has most (if not all) of the goodness of Gerrit, but is trivial to set up (SaaS) and integrates smoothly with GitHub. Every PR becomes a review and gets automatically updated whenever you push to the branch. Disclosure: I'm the founder.
- eridius 11y ago
  Wow, the described feature set sounds pretty good. I'll definitely look into this. However, I will say the demo is a bit odd. It's pretty much impossible to look at the code diff because there are comments everywhere. And the code diff appears to default to not actually showing a diff (the left and right diff bounds are both set to the latest version), which is especially confusing when it shows side-by-side since it's showing the same revision on both sides.
  - piotrkaminski 11y ago
    Sorry about the mess on the demo review -- since everybody gets write access to try things out, it tends to get messy over time. I just reset it now so it looks clean again, and should probably just stick the reset script in a cron job... It's really odd that you got a nil default diff range. I can't reproduce it with either anonymous or authenticated access. If you can, could you please open an issue with more details so I can debug? Thanks!

piotrkaminski 11y ago

The article isn't particularly well written or argued, but it does have a core of truth to it: serious code review in GitHub is painful. However jumping straight to Gerrit to solve that problem seems like overkill to me. Sure, you get a really powerful and extremely configurable code review system, but you have to retrain for a new (and honestly a little long in the tooth) UX and spend time administrating the system. A lighter-weight SaaS like https://review.ninja https://review.ninja, https://omniref.com https://omniref.com, or https://reviewable.io https://reviewable.io (disclosure: this one's mine) might be a more appropriate solution. Specifically to the article's points, Reviewable has a nice reviews dashboard and will show inter-commit diffs within a PR (whether you're rebasing/amending or not), hiding any files with no changes since you last looked. Its default review completion criterion is that all files have been marked as reviewed by at least one person and there are no unresolved discussions still going on, but you can customize this to your team by writing a snippet of code to run against the review's state, e.g. to implement LGTM approval or even a voting system. Reviewable will also update a status check on the PR so you can enforce review completion before merging if that works best for your situation. Best of all, because both systems integrate tightly with GitHub, there's no need to learn a new workflow or mess around with new git commands. Gerrit still has its place but I don't think it should be the tool of first resort. (Edit: added mention of Omniref.)

eeZi 11y ago
Just use Phabricator! It's the best code review system I've used so far. Many large open source projects and companies have adopted it. Someone neatly wrote up the main advantages: http://cramer.io/2014/05/03/on-pull-requests http://cramer.io/2014/05/03/on-pull-requests Phabricator's issue tracker is also an excellent choice over GitHub's simplistic issue tracker. Also, Gerrit isn't that hard and I've seen small teams get productive with it within a 1-2 weeks. No need to reinvent the wheel! By the way: I live in Europe and I haven't worked for one single company which would allow their developers to host proprietary source code with a third party SaaS provider.
- piotrkaminski 11y ago
  Phabricator is nice, but it's more of a full-featured replacement for GitHub as a whole. Some people want to keep most of GitHub and just improve on the code review aspects. > By the way: I live in Europe and I haven't worked for one single company which would allow their developers to host proprietary source code with a third party SaaS provider. Fair enough, companies vary widely in their acceptance of SaaS -- though Reviewable has plenty of European customers too. But to clarify, neither Review Ninja nor Reviewable (not sure about Omniref) actually host code themselves: they just access it through GitHub APIs without storing it. You can also deploy Review Ninja (and soon Reviewable) on-premises, though of course that means you're on the hook for administrating the system again.

1_800_UNICORN 11y ago

Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA. The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. It's unrealistic to ask someone to code review multiple commits per feature, and if you tie in your CI it doesn't make any sense to run your build over and over again for a single feature either. The patchsets DO allow you to see the history of a code review if you have to make changes, but I'd much rather see that live in my git history rather than in Gerrit's history. It's a dirty solution to have to amend your commits to make changes. Nowhere does the author mention how painful it is if you finish a feature, are waiting for a code review, but have to start the next feature using the code you just wrote. Maybe I'm missing some magical feature in Gerrit that makes this easy, but if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle.

oautholaf 11y ago
That's funny, as someone who has used both github and gerrit for several years each, I completely disagree. I found the gerrit flow worked well. At the gerrit-based shop, we kept very good discipline of regular, small checkins. And yes, you can pipeline your checkins too. I found the gerrit flow also much easier to explain to new engineers. The github PR flow is much more full of sharp edges.
djsumdog 11y ago
I used Gerrit for over a year at one company and I have to agree. Every minor change required amending a commit and another review. It really breaks a lot of the git process. I also had to admin a Gerrit server once and the documentation (at the time at least) for setting up and running a Gerrit server was total shit. It was a painful process to say the least. Another project, which took many of my old team members, started using Gitlab instead and they loved it. The merge requests made a lot more sense. I'm currently at a new company that uses Gitlab and I have to agree. Both systems are pretty much suggestive. We could always +1 a code review ourselves if it had to get out that day, but it's best someone else did it and there was a record. Gitlab is a lot more lose. There's no official field for an approval, but you can put in a nice little thumbs up emoji in your comment, and you have the same audit trail. TL;DR +1 Gitlab (et al.) over Gerrit for sure

jessegreathouse 11y ago

Out of the frying pan and into the fire. I don't like Github but, from the sound of it, Gerrit is more complicated which is what I don't want.

brown9-2 11y ago

Gerrit is being used by many large open source projects, It should be worth noting that those large open source projects have very, very different needs than a small development team working on a product together. The open source project likely isn't doing weekly releases (which require some sort of manual QA process, in the source article). A large open source project has hundreds of contributors, where reviewer time is scarcer than contributor time (and the pool of people to approve and commit a change is much smaller than the contributor pool). I think the OP's real problems are that: - an increased release frequency requires them to do more QA - their time spent in code review seems to be a function of how often they are "releasing", not how often people are making changes If the difficulty of making a release increases as you increase your release rate, you might be doing "agile" in a poor way.

u801e 10y ago

> As soon as someone added changes to their pull request – either by rebasing in the new changes or making it as a new commit – you lost track of the comments in the code and viewing what had actually changed since the last update became really hard (almost impossible if the new push was rebased with the new changes). We use github at work with a feature branch workflow (as opposed to gitflow). We've adopted a system where pull request comments are addressed through the use of "fixup" commits. For example, when a pull request is submitted for a feature branch that contains 3 commits, and a comment is made regarding part of the change, the person who submitted the PR will add a commit that addresses the comment with a commit title of: >> fixup! Title of the commit to update >> >> An explanation of what this commit does and why >> ... This, incidently, is exactly what git commit --fixup <commit_ref> does. Then the person responds to the comment saying that it was addressed in <commit_sha1>. As a reviewer, it makes it easy to see that my comment has been addressed and exactly what change was made to address it (by clicking on the link that github autogenerates from the sha1 in the comment). Once the review process is complete, the person will run git fetch origin and then git rebase -i --autosquash --keep-empty origin/master to actually reduce the set of commits down to the original clean set of commits. They then run a git diff <original branch head sha1>.. to verify that there are no differences and then they merge the PR using the merge button in the web interface. This way, you end up merging a clean set of commits for each PR, and it's still relatively easy to keep track of comments and incremental code changes addressing those comments during the PR. In fact, multiple developers can collaborate using the same branch by pushing up "fixup!" commits. Though they need to make sure that they fetch/merge or pull before they push to avoid unwanted merge commits within the branch.

ngrilly 10y ago

Exactly why I'm frustrated with GitHub's PR: > As soon as someone added changes to their pull request – either by rebasing in the new changes or making it as a new commit – you lost track of the comments in the code and viewing what had actually changed since the last update became really hard

dpc_pw 10y ago

I would never ever recommend gerrit to anyone.

killface 10y ago

Blech. I have to use Gerrit at one of my current clients, and I fucking hate it. Github's workflow is easy. You have a repo, you can fork it or create a feature branch, you can add multiple commits, and then open a PR. That makes sense. And the interface is pretty. In Gerrit, I still do commit-as-you-go, because that's the entire fucking point of Git. If I wanted SVN semantics in my repo, I'd use SVN. Then, we have to squash all the commits (I'm very anti-history-revision, but I know that's an opinion) and push up to a different origin. And god forbid if you want to work from that code point in a new branch while you wait for a review. Oh, and if you want to fix some issues found in review? Yeah, let's edit the history again... Oh, and there's a change id created that causes all kinds of other headaches. I have tools to manage and make sense of my git history. I absolutely hate things that force me to modify history. It might as well be voodoo magic when stuff goes wrong. It's often easier to blow it all away and start over. I do like the things it can help you enforce -- a good build and +1/+2 code review etc. But that's not enough to deal with all the little annoyances in gerrit. Especially since it's available in a much better tool -- gitlab. Gitlab is what comes after github has run its course for your team. It's got the same predictable and useful feel, it integrates great with CI tools, and it allows a similar GHPR-style way of merging. There's also BitBucket Server and other stuff.. but Gitlab has my vote in the strongest way possible.