git rebase flow with code review? Possible?

Question

Yes, another git flow question.. :(

I know the 'standard' git rebase flow pretty well:

• Developer creates a tracking branch (say 'featureA') off of an upstream branch (say 'master')
• Developer codes, commits, pulls with rebase, codes, commits, pulls with rebase, etc
• Code is done, developer squashes commits and pushes to master

The issue I'm having is that this leaves no room for code review prior to merging with the master. Reviewers see the changes only when it's on the master, so if the developer needs to tweak anything there will be multiple commits on the master for a given feature. Ideally there is only one.

A few options that I know will solve this but are not ideal:

• Have the developer push the feature branch to the remote. The issue with this is that after they've rebased from master the push would have to be a force push, which while probably safe in this case is not something I want to be business as usual.
• Don't rebase upstream changes to the feature branch, merge them. With this I can't squash the feature branch and push the commits back to the master (right??)
• Use gerrit / github. I have to guess though that there's a way to achieve this in pure git?

Is there a better way?

Answer 1

There are some 3rd-party tools that allow a more sophisticated review workflow. We are currently evaluating a workflow based on Gerrit.

One possible Gerrit workflow could look like this:

• A developer commits into a feature branch. When done, he squashes the feature branch and rebases it onto the current master.
• The code review software prohibits pushing into the master branch directly, so the developer then pushes the feature (squashed to one commit) into the review system where it can be reviewed. Gerrit transparently handles each review request as a seperate branch that is merged (cherry-pick is also posssible, but not default) when review is complete.
• If a change does not pass code review, the developer can amend the commit and re-push the commit to the review system. The software reckognizes if multiple (amended) commits belong to the same feature review request. When review is finally complete, only the latest commit is merged into the actual master branch.
  Of course, since every feature is only a single commit, it is not possible to trace the tweaks that the developer performed during code review (however, as I understood you, this is actually desired). The history of each review request is managed by Gerrit, however, so nothing is really lost.

We are still evaluating a workflow similar to this ourselves, but do not yet use it in production. So I cannot make any statement on how well this approach actually works in a real-world scenario. My point however is, if you are interested in more complex review workflows with Git, Gerrit might be worth a look.