Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Abandoning Gitflow and GitHub in favour of Gerrit

beepsend.com

Post reply on HN
Print view View original

101–110 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#101

Post by davnicwil »

klibertp wrote: post #94
davnicwil wrote: post #35

Earlier quoted context omitted.

> 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 branc…

> It's necessary to have a less-stable, separate, ...ok, I guess... > develop branch where features ...what? Why shouldn't I call my branch for integrating code... integration , or something? > 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. It's not nice; it's wrong. Who is going to checkout a project code?…

> Why shouldn't I call my branch for integrating code... integration, or something?

You can :-) gitflow is just a pattern, the names of the branches are an implementation detail. Just using develop here as it's the name used in the parent's question.

> A very typical scenario is when a new dev joins the project, hacks happily on branch forked from master and finally submit the PR with fixes which were already done..

Gitflow like any branching strategy requires that people using it understand it first, to work. Obviously it's always better to craft these things in ways which help people fall into the pit of success, but if you have new devs just cloning a project, branching however they assume is ok and then fixing bugs that others are working on etc, without once asking a question or being instructed in even the simplest way on what to do (saying 'we use gitflow on this project, development branch is called X' in the readme for example), that's a problem that no branching strategy is going to solve!

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#102

Post by eridius »

piotrkaminski wrote: post #98
eridius wrote: post #89

Earlier quoted context omitted.

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 i…

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 detai…

Thanks, the demo review is now much easier to read.

Also, now that you've reset it, all the diff ranges are now defaulting to the widest view instead of defaulting to just the current revision. Given that I can no longer reproduce it, I'm not sure there's any more detail I can add (beyond the fact that I'm using Safari 9.1 on OS X 10.11.4).

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#103

Post by timr »

eridius wrote: post #82

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 complica…

I've been working on a code-review tool that does exactly what you want: https://www.omniref.com/code_review

It works seamlessly with GitHub, and provides code reviews that end up "sticking" to your code, and documenting its development. Every pull request you create can become a review automatically, or you can pick-and-choose which pull requests to review. And you don't lose reviews or comments when you push to a branch under review.

Also, it lets you dive into the history of a single line of code. For example, here's a line from GitHub's libgit project, annotated with the pull request that created it: https://www.omniref.com/repositories/libgit2/rugged/files/li...

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#104

Post by 1_800_UNICORN »

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#105

Post by eeZi »

piotrkaminski wrote: post #96

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.…

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

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#106

Post by davnicwil »

daxfohl wrote: post #78
davnicwil wrote: post #35

Earlier quoted context omitted.

> 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 branc…

A common case where this doesn't work well is embedded code. You'll frequently have many different releases of your code "in production" at the same time. I started an embedded project a while back using the gitflow style I was used to, but eventually found the meaning of "master" to be not well defined, once we had different release versions and variations. We eventually killed master, and renamed "develop" to "mast…

That makes sense, but I don't understand how renaming the branches made that problem go away.

Also, if you had different variations of builds etc (I assume for different target hardware) could it have been better organised by putting all the common code in a different project, then creating separate projects for each of the variations with that common code as a dependency? Then you could probably manage each of the variation projects with gitflow as usual.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#107

Post by piotrkaminski »

eeZi wrote: post #105
piotrkaminski wrote: post #96

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.…

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 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.…

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#108

Post by _yp »

piotrkaminski wrote: post #107
eeZi wrote: post #105

Earlier quoted context omitted.

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 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.…

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 -- thou…

> 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.

That's the nice thing about Phabricator, you can switch off all features you don't need, and it integrates with GitHub. You can definitely use it just for code reviews, with users logging in using their GitHub accounts and the repositories being hosted by GitHub.

> 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.

That would work! Third party SaaS probably includes Github.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#109

Post by _yp »

edgan wrote: post #93
aeorgnoieang wrote: post #12

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

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.

Try Phabricator (http://phabricator.org/), you can point it at a remote repository without hosting it.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#110

Post by oautholaf »

1_800_UNICORN wrote: post #104

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…

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.

Post reply on HN