Branch for each developer in GIT repo

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

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