On Thu, Feb 11, 2010 at 01:27:47AM -0800, FlashWebHost.com wrote: > Hi, > > We are a small team of 4 programmers. So far we all worked on same > repository, only I do the commit, rest of the 3 programmers make > changes, i verify the code changes and commit. Recently there are lot > of changes in the code, i could not validate all the changes in time. > I find it difficult to validate. > > Recently i installed git all on programmer computers and they studied > the basic operations. I need the programmers work on their own copy of > repo and commit them self. > > We have a remote repository, setup in gitosis. If i allow everyone to > commit to it, there can be many errors or unwanted changes. Should i > create remote repository for each programmers ?
Short of that, you could use the integrator model where you publish a read-only git:// URL that only you or a designated developer pushes to. Developers base their work off of that repo in topic branches. When they have changes that are ready they export patches and mail them to a mailing list where everyone can review everyone else's work. It's a great, simple workflow and is the one used on git, linux, and other projects. This is all spelled out from the POV of a contributor in git.git's Documentation/SubmittingPatches. The real killer benefit is the built-in code reviews. Sending patches to a list makes everyone much more careful about what goes in. It also distributes the burden of validating and verifying the changes since presumably anyone can review anyone else's work. The increased visibility is very valuable. Hang around the git developer list and you'll witness it first hand. You could also let them have their own remotes, but if you have a small team then it might be simpler to just point directly at their repos (assuming you have shared nfs or ssh-accessible paths) and pull from their topic branches post code-review. Having the extra remotes might be an unnecessary burden, but you won't know that until you've experimented and found what works best for you. It could even be better; you won't know until you try. > Can some one give some tips or links where i can find about managing > small project with git ? > > Thanks, > > Santhosh The railsconf gitcast goes into different workflows towards the end of the presentation. http://www.gitcasts.com/posts/railsconf-git-talk Everyone-with-their-own-repos is a workflow encouraged by sites like github and gitorious, so their documentation should translate over well into what you're trying to do if you go down that route. Lurk around on the git mailing list and you can see the workflow I described in practice. It's a very valuable experience. You'd be implementing it on a much smaller scale, but it sounds like you do want there to be a quality-control valve. Thus, the patch-based workflow makes a lot of sense. -- David -- 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-us...@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.