On Mon, 14 May 2012 05:44:40 -0700 (PDT)
mike <mikaelpetter...@hotmail.com> 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
> 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?
I would say that "integration manager workflow" is too heavy-weight for
your case.  I would go this route instead:
* Setup a centralized repo (as you're an F/OSS project, that would most
  probably be done for your anyway by your selected project hoster).
* Grant every developer in your project commit access.
* Devise a suitable branching model and make up a policy which reflects
  this model.  It should be communicated to your developers and to any
  newcomers which are to be granted commit access.

The branching model basically mean how you want to track unstable,
pre-release and released code.
For instance, you could decide that the "master" branch holds unstable
code, and any time you're preparing the next release, you fork a branch
named, say, "1.2.3" (to indicate a version) off "master" and all the
development which should land in v1.2.3 goes there.
Or you can have "master" to always contain stable or at least somewhat
stable code, and have a special branch named, say, "devel" containing
unstable code, which gets merged into "master" from time to time, when
it stabilizes.

In any case, the development should be centered around branches: any
feature should be developed on its own branch and then merged to some
other branch which is "main" with regard to that feature branch.

[1] has a pretty good explanation of how development of a typical
small- to mid-sized Git project might happen, hence recommended to read.

1. http://nvie.com/posts/a-successful-git-branching-model/

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
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