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

> 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.


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.


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 
For more options, visit this group at 

Reply via email to