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

71–80 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#71

Post by gknoy »

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…

The argument made to me by a coworker (for why we should squish + rebase all PRs before merging) was that it makes it easier to use `git bisect` -- which is basically a binary search for Where a Bug was Added.

In practice, I've never done this. I think it's that I work on a smaller codebase, or that I am 1/3 to 1/2 of the developers, and so it nearly always has seemed easier to read the code + tests, and poke at values in a debugger, than to use binary bug search. If I were on a larger team, or a larger project, `git bisect` might be more useful.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#72

Post by HolyHaddock »

Touche wrote: post #66
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…

> 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". I'm not following this at all... what is it you need from this tool and why? > Does it matter that you had to implement 12 fixups at various points and rewrite the whole feat…

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

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#74

Post by jeremiep »

sopooneo wrote: post #59
jeremiep wrote: post #45

Earlier quoted context omitted.

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

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?

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#75

Post by Touche »

HolyHaddock wrote: post #72
Touche wrote: post #66

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". I'm not following this at all... what is it you need from this tool and why? > Does it matter that you had to implement 12 fixups at various points and rewrite the whole feat…

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

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#76

Post by yxlx »

quicklyfrozen wrote: post #62
ssmoot wrote: post #50

Earlier quoted context omitted.

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

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

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?

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#77

Post by xori »

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

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#78

Post by daxfohl »

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…

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 "master", and that particular project makes much more sense now.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#79

Post by mbell »

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, 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 together, that is just a feature branch like all others. Multiple people can work on a feature branch and test their integrations there.

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

I think largely your assumptions are based on a slow moving release cycle, not everyone operates that way. We regularly release multiple versions a day in most of our repos.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#80

Post by balls187 »

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.

Post reply on HN