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

21–30 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#21

Post by distances »

ozim wrote: post #9

What I miss in article is for how long they are on it. Is author after peak of inflated expectations? I have used Gerrit in my previous team and it did not worked so well. Hanging vetos on -2 are not that nice when you have to push feature forward, like instead of blocking it someone else could just fix it, by the time you talked person who put -2 to change it to -1. But maybe with more mature team it would not be a…

I think there's something amiss in your development process if you feel you can merge changes that have -1. What's the point of a review in this case?

There's always hurry, but skipping reviews (and often unit testing too) is a sure way to make sure you'll keep busy fire-fighting in the future.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#23

Post by therealmarv »

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

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#24

Post by stepanhruda »

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

Github just added a way to squash pull requests to a clean commit last week, so there's that

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#25

Post by stepanhruda »

StavrosK wrote: post #15
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…

What's wrong about what he said? Which step can you omit?

Forking the repo

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#26

Post by hinkley »

oluwie wrote: post #8
thesis wrote: post #3

We tried Gerrit. We ran as fast as possible away. It seemed to hate merge commits, and would hang up often. I'm not sure if it's changed at all, but I think the only option was to review every commit individually inside of a branch. It seemed to really be pushing us towards squashing a branch and pushing that up.

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 that as someone who has administered CVS, SVN and Perforce repositories on behalf of my teammates but wants nothing to do with administering Git.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#27

Post by simula67 »

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 to the repo and you are on github, atleast you can change the default branch ( which for a repo I contribute to, I don't )

Anyone know the need for a seperate 'develop' branch ?

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#28

Post by arjie »

StavrosK wrote: post #15
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…

What's wrong about what he said? Which step can you omit?

It needs the context. I've quoted the whole thing below:

> 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. With Gerrit, you could clone the main repository, do your change and then push it directly to the same remote as you cloned it from.

The objection would be that you can always push to a branch and issue a PR from there in GitHub too. Those steps are identical for both tools in a professional setting.

There are reasons for Gerrit but this isn't one.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#29

Post by masklinn »

StavrosK wrote: post #15
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…

What's wrong about what he said? Which step can you omit?

You don't need to fork the repository or push to your own fork (if you have write access to the original obviously, but gerrit seems to assume that), intra-repository pull requests are perfectly well supported.

You do need to create the pull request, but that's no different than pushing to a special magical ref.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#30

Post by sytse »

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…

I fully agree with using master for development. I also think that the git flow process is over the top for most teams. I detailed how to adopt just the things you need in GitLab flow.

"you lost track of the comments in the code and viewing what had actually changed since the last update became really hard" I don't understand why comments in the code would disappear. Line-comments on the code might disappear when lines are changed. We're adding a feature to GitLab where you can acknowledge line comments. And viewing changes is pretty easy as long as you don't rebase.

Post reply on HN