Mercurial_ The Definitive Guide - Bryan O'Sullivan [40]
A sprint or hacking session in a coffee shop is the perfect place to use the hg serve command, since hg serve does not require any fancy server infrastructure. You can get started with hg serve in moments, by reading Informal Sharing with hg serve. Then simply tell the person next to you that you’re running a server, send the URL to them in an instant message, and you immediately have a quick-turnaround way to work together. They can type your URL into their web browser and quickly review your changes; they can pull a bug fix from you and verify it; or they can clone a branch containing a new feature and try it out.
The charm, and the problem, with doing things in an ad-hoc fashion like this is that only people who know about your changes, and where they are, can see them. Such an informal approach simply doesn’t scale beyond a handful of people, because each individual needs to know about n different repositories to pull from.
A Single Central Repository
For smaller projects migrating from a centralized revision control tool, perhaps the easiest way to get started is to have changes flow through a single shared central repository. This is also the most common “building block” for more ambitious workflow schemes.
Contributors start by cloning a copy of this repository. They can pull changes from it whenever they need to, and some (perhaps all) developers have permission to push a change back when they’re ready for other people to see it.
Under this model, it can still often make sense for people to pull changes directly from each other, without going through the central repository. Consider a case in which I have a tentative bug fix, but I am worried that if I were to publish it to the central repository, it might subsequently break everyone else’s trees as they pull it. To reduce the potential for damage, I can ask you to clone my repository into a temporary repository of your own and test it. This lets us put off publishing the potentially unsafe change until it has had a little testing.
If a team is hosting its own repository in this kind of scenario, people will usually use the ssh protocol to securely push changes to the central repository, as documented in Using the Secure Shell Protocol. It’s also usual to publish a read-only copy of the repository over HTTP, as in Serving Over HTTP Using CGI. Publishing over HTTP satisfies the needs of people who don’t have push access, and those who want to use web browsers to browse the repository’s history.
A Hosted Central Repository
A wonderful thing about public hosting services like Bitbucket is that not only do they handle the fiddly server configuration details, such as user accounts, authentication, and secure wire protocols, they provide additional infrastructure to make this model work well.
For instance, a well-engineered hosting service will let people clone their own copies of a repository with a single click. This lets people work in separate spaces and share their changes when they’re ready.
In addition, a good hosting service will let people communicate with each other, for instance to say “there are changes ready for you to review in this tree.”
Working with Multiple Branches
Projects of any significant size naturally tend to make progress on several fronts simultaneously. In the case of software, it’s common for a project to go through periodic official releases. A release might then go into “maintenance mode” for a while after its first publication; maintenance releases tend to contain only bug fixes, not new features. In parallel with these maintenance releases, one or more future releases may be under development. People normally use the word “branch” to refer to one of these