Am 24.07.2011 14:16, schrieb Thomas Adam: > On 24 July 2011 13:12, Mathew Benson <mathew.benson@xxxxxxxxx> wrote: >> I'm planning to use git for a work project, which requires tight control of the peer review process. In previous jobs, the peer review was a tedious manual process of creating PDF files, writing comments in spreadsheets, and copying comments to the CM system. I want to use technology to my best advantage. >> >> Once a developer has completed all his changes in his development branch, what's the best way to get those files to the reviewers, without requiring the author to stop work? First, I think I should create a tag in the developer branch. Each developer has a local repository, and my review tool writes files directly in the work area. Can they just fetch, checkout a tag (don't know how to do that), commit changes, and push it back to the central repository? Is there a better workflow?-- > > This is what Gerrit is useful for. Yes, Gerrit is a very sophisticated way to do that. But you can also achieve a review process by just using git and email too: Have each developer do each topic of his work on a separate feature branch and send merge requests (e.g. per email) to the reviewer when he is done. If the reviewer approves the changes, he merges that branch (and deletes the remote topic branch, as that topic is now finished and part of the history). If not, he requests improvements from the developer who updates that branch and sends another review request when he is done. We use this approach successfully at my dayjob. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html