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

91–100 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#91

Post by daigoba66 »

balls187 wrote: post #80
websitescenes wrote: post #10

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

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

Team members can also work in their own private branches that are pushed to a single repository - that's usually sufficient as a "backup".

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#92

Post by goldbrick »

balls187 wrote: post #80
websitescenes wrote: post #10

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

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

Why would you not be able to use Github as a backup? Github keeps all the branches that are pushed to it, as any git repo.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#93

Post by edgan »

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#94

Post by klibertp »

davnicwil wrote: post #35
simula67 wrote: post #27

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…

> 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? End users? If so, then it makes sense. However, if it's just developers, it's fair to assume that they do the checkout to develop the project, and so making master a production branch gets in their way. 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, and probably already done in a different way, so you have both time wasted and merge conflicts. Don't do that! At the very least set your develop branch as the main one on GitHub, but that's still not as idiot-proof as just using master for development and separate branches and/or tags for production releases.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#95

Post by davnicwil »

mbell wrote: post #79
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, 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. I don't think it's _necessary_ by any means. e.g. We auto-deploy the HEAD of master, assuming tests pass and don't use any special integration branch. If you have some set of features that need to ship toget…

Within gitflow it is definitely necessary to have an integration branch - it doesn't really matter if you call it develop, or you progressively merge different features branches down together, or group them into one feature and just develop them all on one feature branch from the get go, the result is the same - you end up with all your code integrated on one, not necessarily always stable, branch.

The idea in gitflow is that you then isolate a snapshot of that integration branch, whatever form or name it takes, as a release branch, and only when that release branch produces a build passing all tests is it then merged to master (and probably tagged).

You mention you auto-deploy from HEAD of master after tests pass - does that mean that code at the HEAD of master may not pass tests, or that you merge code to master only if it has passed tests. If it's the former, then you're not using gitflow, and I was just explaining the use of separate master and develop in gitflow, not implying that this is the one true branching/release strategy. Using something other than gitflow can work equally well. If the latter, then you are using an integration branch - the one you run the tests on before merging to master.

As to the point about release frequency, having a set of features to release in batch was just an example - if you're in any situation where other developers may commit things to the branch that will ultimately be released from between the time you create your feature branch and the time you merge it, then gitflow is useful - be that on a scale of minutes, hours, days or weeks.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#96

Post by piotrkaminski »

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://omniref.com, or 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.)

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#97

Post by daigoba66 »

marssaxman wrote: post #67
masklinn wrote: post #46

Earlier quoted context omitted.

Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches". This is combined with most of the "historical record" really being worthless garbage: does it matter that you had to implement 12 fixups at various points and rewrite the whole…

I've yet to find a situation in which I cared even a little bit about the prettiness of a git history. I am having trouble thinking of more than a couple situations, ever, where I cared about the contents of a git history, at all! I imagine that people must be doing something involving git history which I simply don't have reason to do, or this "make your history pretty by rebasing" meme wouldn't keep floating around…

I think, based reading comments and articles from various sources, it's all because of GitHub pull requests. A lot of people seem to rather a pull request be represented as a single commit.

But I'm in your camp: I work with teams using git (and GitHub as a central repository), and a non-linear history has literally never been an issue. Even ugly graphs 7-10 histories wide aren't an issue. We also don't do pull requests (because we would we?).

We don't have a hard time with code reviews just using GitHub's commit history or even Gitk. In fact merge-commits often sometimes useful as markers of when the developer integrated his/her changes.

Admittedly, I'll occasionally do a rebase of upstream changes before I push if I know the change I made was small an isolated - but I certainly don't encourage other developers to do it.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#98

Post by piotrkaminski »

eridius wrote: post #89
piotrkaminski wrote: post #85

Earlier quoted context omitted.

You might want to check out 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.

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 details so I can debug? Thanks!

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#99

Post by piotrkaminski »

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 https://reviewable.io then. Just code review, runs on top of GitHub, no extra repos to manage. (Disclosure: I'm the founder.)
Post reply on HN