Git Integration Manager Workflow -- one or multiple repositories?
I've read about the [Integration Manager Workflow][1], and it looks very suitable for our development process (one lead developer for the project, who reviews the work of fellow developers before it's committed to the project's repository). 

However, one thing is unclear to me. In [this visualization][2] in the Pro Git book (and the text with it) it appears as though each developer has his own (remote) repository to push to. In [this chapter][3] (section "Private Small Team"), though, they seem to be using branches to achieve the same kind of workflow.

Is this correct? Which tactic should we use; branches or multiple repositories? I'm guessing it's harder to maintain a timeline of commits if you pull work in from a different repository?


  [1]: http://progit.org/book/ch5-1.html
  [2]: http://progit.org/figures/ch5/18333fig0502-tn.png
  [3]: http://progit.org/book/ch5-2.html
Git Integration Manager Workflow -- one or multiple repositories?
===

I've read about the [Integration Manager Workflow][1], and it looks very suitable for our development process (one lead developer for the project, who reviews the work of fellow developers before it's committed to the project's repository). 

However, one thing is unclear to me. In [this visualization][2] in the Pro Git book (and the text with it) it appears as though each developer has his own (remote) repository to push to. In [this chapter][3] (section "Private Small Team"), though, they seem to be using branches to achieve the same kind of workflow.

Is this correct? Which tactic should we use; branches or multiple repositories? I'm guessing it's harder to maintain a timeline of commits if you pull work in from a different repository?


  [1]: http://progit.org/book/ch5-1.html
  [2]: http://progit.org/figures/ch5/18333fig0502-tn.png
  [3]: http://progit.org/book/ch5-2.html