Great. That confirms what I thought. Thanks.
On Jul 24, 2011, at 9:37 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
Show 18 quoted lines
> Am 24.07.2011 14:16, schrieb Thomas Adam:
>> On 24 July 2011 13:12, Mathew Benson <mathew.benson@gmail.com> 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.