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

161–168 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#161

Post by sytse »

djsumdog wrote: post #113
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…

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

Glad to hear you like GitLab! And if you want something more formal GitLab EE has merge request approva; https://about.gitlab.com/2015/06/16/feature-highlight-approv...

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#162

Post by djtide »

superuser2 wrote: post #126
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…

Phabricator[0] is awesome. Diffs (like PRs) contain several commits, but are reviewed, discussed, and "landed" as a unit with an auto-generated commit message referring to the Diff description and a link to read its history, but "master" is a linear sequence of Diffs being landed. You can also configure all kinds of rules like "X person must sign off on any changes to this file" or "do not merge code to master unless…

hopefully it's slightly less clunky today, just wrapped up the semi-annual refresh this past week. Still... we have our fair share of "-isms".

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#163

Post by jacobsimeon »

ngrilly wrote: post #159
jacobsimeon wrote: post #153

Earlier quoted context omitted.

Your argument would be better received sans-ridicule. I think the OP's point was that Garret hides a lot of features that are built into git and then attempts to paper over that fact by re-implemting those features within its own system. In your first paragraph, you defend Garrit's rebasing procedure and then you implicitly accuse the OP of not being willing to "suck it up and learn something new". Why should we lear…

There's nothing ridiculous in xyzzy_plugh's argument. The discussed tool is not "Garret" or "Garrit", it's Gerrit, which makes me wonder if you used it before commenting. As far as I know, Gerrit doesn't reimplement git's features. Rebasing is done using git rebase. Gerrit is a system for code review, just like GitHub's PR, but with a different approach.

"Look at this guy mispelled the name of something. He must not know how to identify ridicule"

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#164

Post by HolyHaddock »

Touche wrote: post #75
HolyHaddock wrote: post #72

Earlier quoted context omitted.

> Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made. This is interesting - even places I've worked that have cared about commit messages have been pretty happy with the entirely content-free "Fixes from code review." Do you summarise code review discussions in the commit messages?

Yes, I do, I try to treat each commit like something that can be read in isolation. But nevertheless, the merge commit will have (if using GitHub) a reference to the pull request where you can see the discussion, which is valuable imo.

Have you had any feedback from colleagues that have found that useful?

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#165

Post by gregmac »

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…

At work, we use master as you describe, and follow gitflow for feature and bugfix branches.

For release-to-customer products, we have a release branch, eg: release/1.2.3, and as part of our CI build, that number is automatically picked up and used in the product itself as the version number.

For our cloud/SaaS/single-instance stuff, we have a 'staging' and 'production' branch, and typically have 3 environments (dev, staging/test, and production) all of which are continuously deployed. We typically just do fast-forward merges to bring staging and production up-to-date with master.

In both cases, when a developer is working on a new feature or fix, we want them to base off master.. which is the latest fully-integrated build, though it hasn't passed QA. If they worked off a production/release branch, we'd continuously have to deal with conflicts as by definition they're basing their changes on out-of-date code.

A 'develop' branch could work for some of our small stuff, where typically production/release isn't far off from master, but for our main stuff we do a 2-3 month release cycle, so master usually has quite a lot of changes that aren't in release.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#166

Post by euroq »

hinkley wrote: post #145
zo1 wrote: post #47

Earlier quoted context omitted.

Would you care to elaborate what you find wrong/bad about "parallel histories"? I'm curious.

This is related to the conversation about squash that happened last week. Basically, the moment two or more people try to work on something outside of the trunk line of code (trunk/master/whatever), there is no version of their commit history that will be pretty, and so squashing the branch at the end seems like a good idea, even though it produces objectively worse code over the long run. To wit: There comes a point…

> By squashing the who and the message are lost. But we think that's okay because it's a lesser evil than having a bunch of commits in trunk. Which is bullshit.

Well, don't erase the message when squashing. My policy is that we take the pull request and use the message title and description as the actual message of the squashed commit, which works great.

Having a bunch of commits IS really bad. One idea = one commit is so much better than some bullshit three commits of "refactored" "made mistake" "back to normal" those are just as worthless to keep in the history as recording your typos+backspaces+fixes into the history.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#167

Post by killface »

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#168

Post by sytse »

Negative1 wrote: post #56

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

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.
Post reply on HN