From: Mathew Benson Date: Sun, 24 Jul 2011 15:32:27 GMT Subject: Re: Help using git I'm review process Message-ID: <01E430F0-0FDC-4FBD-9973-0E5B437FACEC@gmail.com> In-Reply-To: <4E2C2E15.8010602@web.de> Great. That confirms what I thought. Thanks. On Jul 24, 2011, at 9:37 AM, Jens Lehmann wrote: > Am 24.07.2011 14:16, schrieb Thomas Adam: >> On 24 July 2011 13:12, Mathew Benson 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.