This site serves as node for gathering useful workflows.
If you use a workflow which isn't yet listed here, please add it.
Contents
And if you use a workflow very similar to one of the workflows here, but with distinct changes, please add a note to the modifications section of the existing workflow.
But if you search for quick hints to some issues, please have a look at the Tips and tricks page and at the list of extensions. Also there is a page with hints for working practices.
Intro
With Mercurial you can use a multitude of different workflows. This page shows some of them, including their use cases.
It is intended to make it easier for you to create your own workflow.
We begin with standard workflows and then go on to more complex examples.
The initial workflows come from the workflow collection in the wiki for http://mercurial-scm.org - would you like to help us convert one of the remaining ones to this page? (please delete this line, as soon as all workflows are transferred).
The workflows on this page are rather terse to give you a good overview. You can find a longer introduction which shows basic Mercurial usage compatible with these workflows in learning Mercurial in workflows.
Structure or a workflow
For whom? -> Why and what does it gain you?
What do you need? -> Which resources and extensions?
Flow -> How to use this practically. Optionally split into
Single Developer workflow -> What do you do?
Sharing changes -> How does your team interact?
Sorting of the entries
- Simple workflows without extensions.
- Complex workflows, including collaborative patch development and similar.
Smoothing workflows with extensions -> i.e. shelve before merging.
Overview and plan
General:
- One-off patch submission
- Lone Developer + laptop + publish
- Simple shared push repository for small trusted teams
- Several pull repositories with integrators for security and large teams
- Personal incoming, outgoing and feature clones
Collaborating on features:
- Shared repo + named branches and bugzilla for feature development
- centralized with attic
- patch branches (pbranch)
Dependency tracking:
- Dependency tracking
- Snapshots
Special usages:
- Working with big binary files
- Tiered web development
- Offsite working on dynamic websites
- automatic trusted group of committers for optionally anonymous repositories
Working with other vcs:
- Dealing with CVS
Neat tricks for smoothing workflows:
- bundle incoming
- shelve before merging
Workflows
One-off patch submission
For whom?
If you just want to submit a short patch to a project, this workflow is right for you.
Requirements
You need just Mercurial (command line) and an email address to which you can send the patch.
Local Flow
First get the repository
$ hg clone http://hg-scm.org/hello
Now edit the files and commit your changes
$ cd hello $ (edit files) $ hg add (new files) $ hg commit -m 'short description of the changes'
Export your patch
$ hg export tip > patch.diff
Note: "tip" is the most current revision in your repository. hg export exports all selected revisions as one change.
Sharing changes
To share your changes, just send the file patch.diff to the developers email address, ideally with a description what your patch does and why it's important.
The developer will then import and test it:
$ cd hello $ hg import patch.diff
Now he has the revision in his local repository. He can test and push it.
Note: You can also use hg import on a maildir file. It will automatically select and import the patch.
Modifications
You can also upload the patch, for example to a bugtracker. It's just a simple file after all.
CVS-like Workflow
For whom?
For people who want to work as in CVS, but with added Mercurial benefits.
Requirements
Only Mercurial.
Workflow
Approval Management: Auditing and QA
For whom?
If you need explicitely approved code history with a full track record using a team of developers and a seperate QA team, this workflow might be right for you.
Requirements
You need just Mercurial (command line), a shared repository for exchanging data (a simple SSH-server suffices, as does a single private bitbucket repository) and the GPGExtension.
Flow
This workflow uses the default branch for development, as well as a QA named branch and a release branch.
The advantage is that merging default into QA requires an explicit merge which can subsequently be GPG signed by the developer responsible for it.
When QA finishes applying their changes, they first of all merge back into default (so that developers work on the QA version) and then merge into release, GPG signing the merge commit.
Developer
hg pull # get the latest changes hg update hg commit -m "<what I did>" hg update -C QA hg merge default hg commit -m "merged default branch for QA" hg sign hg push
QA
hg pull hg update QA hg commit -m "QA fixes" hg update -C default hg merge QA hg ci -m "merged QA fixes back into the development branch" hg update -C release hg merge QA hg commit -m "merged finished QA into release" hg sign
Modifications
If you need more layers than just developers and QA, just add additional named branches, for example staging-release before release.