Hi Mike,


a) you're all used to CVS and are used to it, and
b) you are a small team of people who are probably all fully qualified to 
decide what goes into the source code

.. I would go for the centralized workflow mentioned first on that page. 
The integration manager workflow only really makes sense when you have a 
lot of programmers, and you carefully need to control when you allow each 
changeset into the mainline.

Once you've grown used to using Git, you can start experimenting with other 

You can still accept patches to the open source project over email, or you 
can instruct contributors to publish their "patches" in the shape of Git 
repos wherever they want to put them (github, etc). You can then merge from 
their repositories, and push to your central repository. That is 
essentially the integration-manager workflow coming into shape.

In the end, the best advice is "just do it", and ask here for help when you 
run into trouble.

On Monday, May 14, 2012 2:44:40 PM UTC+2, mike wrote:
> Hi,
> We have been using CVS for a long time in our open source project. We now 
> have the intention to switch over to git. We use Eclipse.
> It is a relatively small project with 3-5 developers spread all over the 
> world and I am mananging/developing this project.
> I found this link:
> http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows and 
> found 
> Integration-Manager 
> Workflow<http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow>good
>  to still have some control.
> Do I need to make anything specific to gain this extra step? Or is there 
> any other way work that would be more suitable for a small group?
> br,
> //mike

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to