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:
> 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
> 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?
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 firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at