Abandoning Gitflow and GitHub

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.

1. 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?
2. 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."