Git Integration Manager Workflow — one or multiple repositories?

Question

I've read about the Integration Manager Workflow , 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 from the Pro Git book it appears as though each developer has his own (remote) repository to push to:

In this chapter (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?

Answer 1

You can use the workflow you linked to but it adds a little more overhead. Biggest advantage is that you can work asynchronously and only need access to the server.

You don't have to use public and private repos though. You can still have a pull based workflow if you have access to the other devs repositories, where the devs commit to their local repos and you pull from them.

So for example. Say dev A is working on branch featureA. He commits to his local branch featureA and lets you know "feature A is ready now, you can pull from me". Here you could setup his repository as a remote like "git remote add devA /path/to/devA/repo.git" and just git pull devA featureA (or fetch first, check the code and then merge).

This of course assumes that you have access to their repositories via eg the network, ssh or http.

Answer 2

This question has been around for a while but the approach given in the question is a valid one. It's called the Forking Workflow . Well, it's very similar to the one above and seems to match it in intent and purpose but at least there's a nice writeup that should clarify the strategy.