Git and HG solve part of the problem of how can a team work together and keep everything in sync. Which is to say that they solve the technical part of the problem. Of course these tools are only as good as the teams that use them. If used badly they can make a very well regimented mess where team members have histories of what they have done but trying to figure out how it all fits together is a nightmare.
To avoid this a team needs clear guidelines on how and when to integrate merges. Those guidelines along with the ideas of how to use GitHub form a workflow.
To figure out what type of work flow several questions will have to be asked. There are several attributes of a project and a team that have to be asked as shown on this table. Of course this table is only a guide, your work flow must match the needs of your project and team.
| Team Members | Well Defined | Amorphous |
|---|---|---|
Team Location |
Distributed |
Co Located |
Time Frame |
On Going |
Limited |
Team Size |
Large |
Small |
Leadership |
Formal |
Informal |
Repository Access |
Public |
Private |
Of course many projects will hit somewhere in the middle on one or those questions. The Linux Kernel team is probably pretty well defined at the core but may be a bit amorphous at the edges. Each work flow presented here will start with a version of this chart for reference.
It should also be noted that a work flow does not have to stay the same over the course of a project. If three friends decide to create a startup when they first start it will probably be three people with laptops writing code late into the evenings over Pizza. If they are successful the team will grow and they may find that what they have been doing so far does not work well for them. In this case they will want to adapt to a new setup.
The advantage of a DVCS is that these kind of changes are at least from a technical point of view pretty simple to handle. Repositories can be cloned and merged pretty much at will. At worst team members may have to change the origin of their repository, or to archive their current repository and clone it anew from a central repository.
Note: It should also note that I have not defined what is meant by "Large" and "Small" in the context of a team. I am assuming a more or less common sense definition in terms of the evolution of a project.
In addition different work flows will differ for public and private repositories. In this case a public repository is a project like this book or the linux kernel which anyone can access on GitHub, bitbucket or the like. Presumably they can also fork the project and submit pull requests (which may or may not be accepted by the project maintainer).
A private repository is one in which only members of a project team can access the repository, and would normally be used for the development internal to a company. Of course the project administrator can invite anyone into a private project.