Mercurial_ The Definitive Guide - Bryan O'Sullivan [42]
Feature Branches
For larger projects, an effective way to manage change is to break up a team into smaller groups. Each group has a shared branch of its own, cloned from a single “master” branch used by the entire project. People working on an individual branch are typically quite isolated from developments on other branches (see Figure 6-1).
Figure 6-1. Feature branches
When a particular feature is deemed to be in suitable shape, someone on that feature team pulls and merges from the master branch into the feature branch, then pushes back up to the master branch.
The Release Train
Some projects are organized on a “train” basis: a release is scheduled to happen every few months, and whatever features are ready when the “train” is ready to leave are allowed in.
This model resembles working with feature branches. The difference is that when a feature branch misses a train, someone on the feature team pulls and merges the changes that went out on that train release into the feature branch, and the team continues its work on top of that release so that their feature can make the next release.
The Linux Kernel Model
The development of the Linux kernel has a shallow hierarchical structure, surrounded by a cloud of apparent chaos. Because most Linux developers use Git, a distributed revision control tool with capabilities similar to Mercurial, it’s useful to describe the way work flows in that environment; if you like the ideas, the approach translates well across tools.
At the center of the community sits Linus Torvalds, the creator of Linux. He publishes a single source repository that is considered the “authoritative” current tree by the entire developer community. Anyone can clone Linus’s tree, but he is very choosy about whose trees he pulls from.
Linus has a number of “trusted lieutenants.” As a general rule, he pulls whatever changes they publish, in most cases without even reviewing those changes. Some of those lieutenants are generally agreed to be “maintainers,” responsible for specific subsystems within the kernel. If a random kernel hacker wants to make a change to a subsystem that they want to end up in Linus’s tree, they must find out who the subsystem’s maintainer is, and ask that maintainer to take their change. If the maintainer reviews the changes and agrees to take them, the maintainer will pass them along to Linus in due course.
Individual lieutenants have their own approaches to reviewing, accepting, and publishing changes, and for deciding when to feed them to Linus. In addition, there are several well-known branches that people use for different purposes. For example, a few people maintain “stable” repositories of older versions of the kernel, to which they apply critical fixes as needed. Some maintainers publish multiple trees: one for experimental changes, one for changes that they are about to feed upstream, and so on. Others just publish a single tree.
This model has two notable features. The first is that it’s “pull only.” You have to ask, convince, or beg another developer to take a change from you, because there are almost no trees to which more than one person can push, and there’s no way to push changes into a tree that someone else controls.
The second is that it’s based on reputation and acclaim. If you’re an unknown, Linus will probably ignore changes from you without even responding. But a subsystem maintainer will probably review them, and will likely take them if they pass their criteria for suitability. The more “good” changes you contribute to a maintainer, the more likely they are to trust your judgment and accept your changes. If you’re well known and maintain a long-lived branch for something Linus hasn’t yet accepted, people with similar interests may pull your changes regularly to keep up with your work.
Reputation and acclaim don’t necessarily cross subsystem or “people” boundaries. If you’re a respected but specialized storage hacker, and you try to fix a