tags:

views:

69

answers:

4

I'd like to move my project to GitHub from local svn repository. Multiple developers are curently working on this project. I was thinking that each developer should have their own branch in which they would commit changes. When manager review their work, he will merge it into master branch. I don't want separate repository for each developer as GitHub has limited number of private repositories.

Is this a good idea? What are other alternatives?

+2  A: 

You wouldn't need to setup different branches for each developer (though you could) in one project we setup an architecture like this:

master
pre-prod
qa
devel

The developers all checked-out the devel branch and pushed against it, the QA team would take the devel branch nightly and pull it into QA and actually review what was done and test on a development hardware platform, pre-prod was then pulled from QA after ~weeks worth of QA or a milestone was reached and was tested on production hardware for "internal-beta" once cleared it was then pushed to master.

If you have multiple developers you may just want to take the time to setup gitolite (or Gitosis) and a remote Git repo. Having each developer have it's own Repo and then either your repo being the "main" or having a main repo which you could pull from each developers repo is ideal and works great in big projects with many collaborators.

However a branch-per-developer layout in Github would also work fine too, depending on how many developers you had and how big the code base was ( only because tedious to performance after ~400MB or long history (lots of deltas) )

Marco Ceppi
Ohh I like what you say, it's pretty much like it is in real companies. It is easier to conceive it when the project is big but we should also do it with little project (maybe pre-prod is supperflous)
pastjean
That layout was what best suited the company and developers for the team who were used to VCS and SVN - The idea is even though Git is meant to be decentralized you can still setup a centralized repository for which to track and maintain code. pre-prod is like a higher level QA but it is pretty superfluous.
Marco Ceppi
+1  A: 

When they clone the repository on their PCs it's called a fork, the thing i would suggest is for them to make git "format-patch" and send it to the manager, which in turns review the patch by applying it and commit to the sentral repository.

It is known as the "Decentralized with human gatekeeper" workflow : http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html (This example is with bazaar but it applies to GIT very well)

The way you think is also good with everyone having a branch. The Decentralized with gatekeeper resembles what the Linux kernel uses

pastjean
In the Linux workflow there are 10 maybe 15 people that Linus actually pulls from as in fetch+merge the rest are patches that are either patches submitted to maintainers or pull requests submitted to them. Patching + merging patches from a management perspective is tedious and although it is very easy to do in Git can be cumbersome especially when it's a development team and not something like an open source project
Marco Ceppi
+1  A: 

In Git, each developer will have their own repository and default branch in which they will commit changes.

Please refer - http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

neduma
Let me add that each developer could have their own *remote* repository, and you could merge them into the main repo when you've vetted changes. It's similar to the OP's branches, just to the next level :)
RyanWilcox
+1  A: 

Scott Chacon did a great job with the Pro Git book. Chapter 5 talks about distributed work flows and I think the Integration-Manager Workflow fits with what you're describing.

Git Pro

Also remember that unlike SVN, every developer will have their own repository, not just a working copy, checked out on their development machine. In that same way, you can clone a bare repository to a shared server on your internal network, have your developers commit to that repo and then have your maintainer pull from the internal repo, integrate changes and then push up to github.

In that workflow, you manage a bare repo on your own machine and control permissions via the regular Unix user accounts. You're not constrained by the number of developers that can push to your internal repo like you would be with Github.

Bryce