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 git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
