The article starts out mentioning open-source projects, but the article sounds like it's talking about team members at the company. I'm assuming that these are private repositories in the organization.
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. 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.
I've never worked for an organization that uses GitHub, but I've never heard of a team using this approach. Always the latter.
With GitHub you would often add the repository of the one creating the pull request as a remote and then check out their feature-branch using git checkout <username of pull-request creator>/feature/<name of feature>. This worked but you ran the risk of checking out code that wasn’t in the pull request (if the PR was locked to a specific hash and not the branch).
I see two problems here.
Why would you have each team member work on their own repository? This is related to the above. Why not just have their branches in the main repo?
If you are using git-flow and are creating a pull request from a feature branch at a specific revision, you're probably doing something wrong. This is an organizational issue.
This article does a good job of explaining how Gerrit is useful but to me it doesn't make a convincing argument that using GitHub was the wrong choice. The arguments made in the article seem a little crazy to me. Each team member having their own repository that you'd add as another remote? Pull requests made from specific revisions? The only convincing part was made in the first section:
As soon as someone added changes to their pull request – either by rebasing in the new changes or making it as a new commit – you lost track of the comments in the code and viewing what had actually changed since the last update became really hard (almost impossible if the new push was rebased with the new changes). With some git-fu you could do a manual diff locally but doing this between multiple pull requests day out and day in added unnecessary stress on the code reviewers.
Everyone knows that GitHub's code review tools aren't the greatest by any means, but you can at least view the outdated diff. The article could probably be summed up by saying, "GitHub's code review tools are lacking and we wanted something better."
I've never worked for an organization that uses GitHub, but I've never heard of a team using this approach. Always the latter.
That is the normal process when accepting pull requests from someone that lacks commit access to the repository. We don't use it for the main developers on the project, but we do occasionally get PRs that way from developers working on other teams within the company.
My good friend works at a company that uses this workflow for all developers and he has no complaints about it. Once you get your fork setup with an origin and an upstream remote, day-to-day work is painless.
Personally, the fact that Gerritt can only handle single commits would be a complete deal breaker.
Yeah, I can see it working out pretty easily but it seems like a strange method to have to clone/checkout someone's feature branch to do whatever.
The only really large project I've seen use Gerrit is the Go programming language and it seems to work pretty well for them but I've yet to try it myself. Handling single commits I don't think would be a deal breaker for me but it definitely loses history. When I go about implementing a large feature I typically implement the pieces in small commits directly related to that functionality with messages such as "Enable user registration" or something like that which makes it easy for others to see the steps necessary for each piece of the feature. Squashing all those steps into one is not as helpful.
You don't have to create per-user local branches in the common case but it is required from time to time. Say you want to mostly accept a PR from a fork but make small modifications first. In that case, I create a local otheruser-master branch that tracks otheruser/master. Then I make and commit my changes before merging otheruser-master into master.
It's slightly tedious but easily scriptable. Currently, we only get external PRs once or twice a month and most can be merged immediately so it's never been a problem. For my buddy using a completely fork-based workflow, the forks of a project are mostly stable (one per team member) so the overhead of managing remotes is minimal.
Amending commits as part of a normal workflow breaks what I view as the golden rule of editing history: never edit a pushed commit.
The article starts out mentioning open-source projects, but the article sounds like it's talking about team members at the company. I'm assuming that these are private repositories in the organization.
I've never worked for an organization that uses GitHub, but I've never heard of a team using this approach. Always the latter.
I see two problems here.
This article does a good job of explaining how Gerrit is useful but to me it doesn't make a convincing argument that using GitHub was the wrong choice. The arguments made in the article seem a little crazy to me. Each team member having their own repository that you'd add as another remote? Pull requests made from specific revisions? The only convincing part was made in the first section:
Everyone knows that GitHub's code review tools aren't the greatest by any means, but you can at least view the outdated diff. The article could probably be summed up by saying, "GitHub's code review tools are lacking and we wanted something better."
dacjames 2 points · Apr 2016
That is the normal process when accepting pull requests from someone that lacks commit access to the repository. We don't use it for the main developers on the project, but we do occasionally get PRs that way from developers working on other teams within the company.
My good friend works at a company that uses this workflow for all developers and he has no complaints about it. Once you get your fork setup with an origin and an upstream remote, day-to-day work is painless.
Personally, the fact that Gerritt can only handle single commits would be a complete deal breaker.
weirdasianfaces 2 points · Apr 2016
Yeah, I can see it working out pretty easily but it seems like a strange method to have to clone/checkout someone's feature branch to do whatever.
The only really large project I've seen use Gerrit is the Go programming language and it seems to work pretty well for them but I've yet to try it myself. Handling single commits I don't think would be a deal breaker for me but it definitely loses history. When I go about implementing a large feature I typically implement the pieces in small commits directly related to that functionality with messages such as "Enable user registration" or something like that which makes it easy for others to see the steps necessary for each piece of the feature. Squashing all those steps into one is not as helpful.
dacjames 2 points · Apr 2016
You don't have to create per-user local branches in the common case but it is required from time to time. Say you want to mostly accept a PR from a fork but make small modifications first. In that case, I create a local otheruser-master branch that tracks otheruser/master. Then I make and commit my changes before merging otheruser-master into master.
It's slightly tedious but easily scriptable. Currently, we only get external PRs once or twice a month and most can be merged immediately so it's never been a problem. For my buddy using a completely fork-based workflow, the forks of a project are mostly stable (one per team member) so the overhead of managing remotes is minimal.
Amending commits as part of a normal workflow breaks what I view as the golden rule of editing history: never edit a pushed commit.