If all of the developers have commit access to the repo, you should not need to do anything special. They will pull changes from the repo, make their own changes, commit locally, and then push back into the public repo when they have something working.

If on the other hand you have one (or a few) developer(s) responsible for committing to the repo, and the others are providing patches to these. Have each of them clone the repo into their own accounts and have them send pull-requests when they have a change they want into the main repo.

It’s also possible to make specific clones for working on specific features if you wish. Using the same workflow with pull-requests to get changes into the main repo when the feature is done.

If by “All developers will have one universal account” you mean that all developers will share one GitHub account and appear as the same committer in the repo, that’s a bad idea. Make separate accounts and set them up as collaborators if you want them all to have commit access.

As for your specific questions:

2. No, use branches for features, fixes etc that will take more than one commit. More than one developer can be working on the same branch.

3. Yes, git handles conflicts really well, so there’s no problems having people work on the same file. No problems except, conflict resolution may not always be trivial if there’s fundamental changes to a file that has been edited by more than one member. This is however nothing that can not be overcome by talking together. Version control does not replace communication.

Good luck!

We work with 2 developers and we use this workflow:

• On Github we have a master branch and a dev branch
• The master branch is the same as production or contains deployment
  ready code
• The dev branch is ahead of master and contains all new code currently
  being worked on
• Locally we both work on the dev branch and push to github when something is ready
• The other dev fetches any new changes from the dev branch before pushing his new code
• When dev branch is good,we merge with the master branch
• Locally we have several feature branches issue branches etc.

I see only text answers here, so I thought I’d post a picture of a nice gitflow to start with. A picture describes more than a thousand words:

• This flow also works good with Continuous Deployment.
• Your master branch contains code that is currently running on your production server.
• Your develop branch contains code that is currently running on a staging/testing server.

I work with 3 other developers, and we struggle with this quite a bit. Developers will sometimes push commits into production that really aren’t ready for prime-time yet because they’ll pull other commits into their changes and then push into production.

Version branches seem to work ok for us. So, if version 1.0 is the current stable version, we will create a branch for v1.1-development. The developers will make changes in this branch. Our testing server checks out this branch and pulls changes as needed.

When all the features for v1.1 are ready to go and testing is done, we will merge v1.1 with master and push.
With branches, developer team A can work on v1.1 and developer team B can work v1.2. Both teams can work without impacting each other. If team A develops something that B can use, you can pull those changes into B without impacting production (this doesn’t happen very often).

We also use a hotfix branch that is used for immediate changes.

Here is a link to a picture of what this looks like.
http://nvie.com/img/[email protected]