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

31–40 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#31

Post by bryanlarsen »

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…

Note that you can change the default branch in github:

https://help.github.com/articles/setting-the-default-branch/

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#32

Post by loopbit »

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#33

Post by pnathan »

hinkley wrote: post #26
oluwie wrote: post #8

Earlier quoted context omitted.

Gerrit does favor rebasing over merging but that's hardly a reason to run away from it

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…

consider mercurial. You may be pleasantly surprised.

edit: spelling

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#34

Post by VLM »

_jb wrote: post #17
chadnickbok wrote: post #2

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

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.

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#35

Post by davnicwil »

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

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#37

Post by Touche »

therealmarv wrote: post #23
chadnickbok wrote: post #2

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

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

I've never understood why people think omitting a historical event keeps their "history clean".

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#38

Post by Laaw »

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#39

Post by Laaw »

kowdermeister wrote: post #19
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.

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.

There are far fewer reasons not to use Gitflow than you might initially think.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#40

Post by cname »

jedberg wrote: post #7
chadnickbok wrote: post #2

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

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.

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