code review with git-flow and github

If you're doing code reviews, then I will assume that you have a central repository that contains the "official" code. Developers pull from and push to this central repository.

When you use Gerrit, Gerrit itself becomes the central repository (it has built-in SSH and HTTP servers that let users interact with it in basically the same way they already are). When using Gerrit, the workflow becomes:

1. Developer makes changes on whatever branch, commits locally.
2. Developer pushes those changes to Gerrit.
3. Gerrit creates review items for others to review.
4. Peers review the code, making comments and accepting or rejecting the commit.
5. When the commit is accepted, then Gerrit makes those changes available for others to pull from the branch.

When using a central repository, other developers can see the submitted changes after step 2. Gerrit introduces the code review workflow, and so other developers only see the submitted changes after step 5.

This works well with git-flow (or any other branching scheme) because Gerrit supports reviewing changes made on any branch.

We stumbled on this exact problem recently. We really like git flow, has it use a good level of semantic (using the same level that you use in team discussion : "I'll start feature A" more than "I'll create a branch, checkout it"), while git is very "implementation" level (which is good and useful also, but different).

The problem we have is with git feature finish, as it merge the branch into the develop, while we want a pull request to be sent and (this is important) merged by the reviewer, not the committer, to emphasize team ownership.

Our current solution :

1. Someone use git flow to create a feature branch
2. When done, he create a pull request (using github)
3. The review take place, with potential additional commits
4. The pull request is merged using GitHub by the reviewer.
5. There is not git flow feature finish (as the branch is already merged)

This is consistent with our practice, with the downside of requiring to delete the branch ourselves (as we do not git flow finish). Our next step will probably be to reimplement some parts of git flow (as it is mainly about chaining git commands) to take this into account (having the "cleaning" part of the finish, without the merge).