Typical SCM activities

Probably the most common use pattern for any SCM, no matter which one is in play, and regardless of the specific command variations, is the following sequence of operations:

• Fetching a version of a given code base:
  • Usually, this will be the most recent version, perhaps from a specific branch for development, but any branch or version that needs to be retrieved could be fetched. In any event, the process will make a complete copy of the requested code base in some location on the local file-system, ready to be edited.
• Making changes to the local copy of the code.
• Reconciling any differences prior to committing changes:
  • The goal with this step is to pull down any changes that have been made to the same code base, and find and resolve any conflicts between local changes and any that may have been made by others in the same code. Several current SCMs allow a local commit before committing to a shared repository. In these SCMs, this reconciliation is, perhaps, not as critical until code is being committed to the shared repository, but doing so with every local commit will often break the resolution of conflicts down into smaller, more manageable chunks.
• Committing to the shared repository:
  • Once this has been completed, the changes made are now available for other developers to retrieve (and reconcile conflicts against, if necessary).

This use pattern will probably encompass most development efforts—anything that involves working on an established branch, and that doesn't require a new branch. Creation of new branches is also not unusual, especially if there are major changes expected to substantial portions of an existing code base. It's also not an unusual strategy to have nested branches for different environments, where the deeper branches are still pending some review or acceptance before being promoted up to the more stable branches.

The branch structure is shown here:

The process for promoting code, for example from the [dev] branch up to [test], is reduced to an upwards merge, copying code from the lower branch to the higher, followed if necessary by branching from the higher branch back down to the lower again.

It's also not unusual to have separate branches created for specific projects—especially if there are two or more efforts underway that are likely to make widespread and/or significant changes, and most especially if those efforts are expected to conflict with each other. Project-specific branches will usually be taken from a shared development branch, as shown here:

As code is completed for either [project1] or [project2] branches, it would be committed to its own branch, then merged up into the existing [dev] branch, checking for and resolving any conflicts in the process.

There are dozens of SCMs available, about a dozen of which are open source systems and free of cost. The most popular systems are:

• Git (by a wide margin)
• Subversion
• Mercurial