120 lines
8.1 KiB
HTML
120 lines
8.1 KiB
HTML
|
<!DOCTYPE html>
|
||
|
|
<html lang='en'><head><meta charset='utf-8' /><meta name='pinterest' content='nopin' /><link href='../../../../static/css/style.css' rel='stylesheet' type='text/css' /><link href='../../../../static/css/print.css' rel='stylesheet' type='text/css' media='print' /><title>Mercurial Workflows: Branch As Needed / Steve Losh</title></head><body><header><a id='logo' href='https://stevelosh.com/'>Steve Losh</a><nav><a href='../../../index.html'>Blog</a> - <a href='https://stevelosh.com/projects/'>Projects</a> - <a href='https://stevelosh.com/photography/'>Photography</a> - <a href='https://stevelosh.com/links/'>Links</a> - <a href='https://stevelosh.com/rss.xml'>Feed</a></nav></header><hr class='main-separator' /><main id='page-blog-entry'><article><h1><a href='index.html'>Mercurial Workflows: Branch As Needed</a></h1><p class='date'>Posted on February 28th, 2010.</p><p>A while ago <a href="http://nvie.com/">Vincent Driessen</a> posted an example of <a href="http://nvie.com/git-model">a successful git
|
||
|
|
branching model</a>. A lot of git users found that article very
|
||
|
|
helpful, and <a href="http://dirkjan.ochtman.nl/">Dirkjan Ochtman</a> <a href="http://twitter.com/djco/status/8061889499">told me</a> I should write a similar
|
||
|
|
article for Mercurial users.</p>
|
||
|
|
|
||
|
|
<p>I decided that I didn't want to just write a single entry about one branching
|
||
|
|
workflow. Mercurial is flexible enough to support many different workflows and
|
||
|
|
some of them will fit a given project better than others. Instead I'm going to
|
||
|
|
write a series of posts, each one about a particular workflow.</p>
|
||
|
|
|
||
|
|
<p>I'm going to start off with the simplest example I can think of: "Don't worry
|
||
|
|
about branching at all, just deal with it whenever it happens."</p>
|
||
|
|
|
||
|
|
<p><strong>Note:</strong> In this series I'm going to assume you're comfortable with basic
|
||
|
|
Mercurial commands and you know how Mercurial's various forms of branching
|
||
|
|
work. If you need some review on Mercurial's commands you should look at the
|
||
|
|
<a href="http://hgbook.red-bean.com/">hg book</a>. If you need more information on branching concepts you might like
|
||
|
|
my <a href="../../../2009/08/a-guide-to-branching-in-mercurial/index.html">Guide to Branching in Mercurial</a>.</p>
|
||
|
|
|
||
|
|
<ol class="table-of-contents"><li><a href="index.html#s1-branch-as-needed-in-a-nutshell">"Branch as Needed" in a Nutshell</a></li><li><a href="index.html#s2-an-example-scenario">An Example Scenario</a></li><li><a href="index.html#s3-branch-setup">Branch Setup</a></li><li><a href="index.html#s4-contributing-to-the-project">Contributing to the Project</a></li><li><a href="index.html#s5-merging-changes-from-contributors">Merging Changes from Contributors</a></li><li><a href="index.html#s6-summary">Summary</a></li></ol>
|
||
|
|
|
||
|
|
<h2 id="s1-branch-as-needed-in-a-nutshell"><a href="index.html#s1-branch-as-needed-in-a-nutshell">"Branch as Needed" in a Nutshell</a></h2>
|
||
|
|
|
||
|
|
<p>The general idea of this workflow is that you don't worry about branching
|
||
|
|
until it actually happens.</p>
|
||
|
|
|
||
|
|
<p>The benefit is that it takes no extra work up front and keeps things very
|
||
|
|
simple.</p>
|
||
|
|
|
||
|
|
<p>The drawback is that it doesn't scale very well. It's great for small projects
|
||
|
|
but it for larger ones you'll probably want something a bit more structured.</p>
|
||
|
|
|
||
|
|
<h2 id="s2-an-example-scenario"><a href="index.html#s2-an-example-scenario">An Example Scenario</a></h2>
|
||
|
|
|
||
|
|
<p>This workflow is most suited to small projects. Here's a sample repository
|
||
|
|
with only a single, linear series of changes:</p>
|
||
|
|
|
||
|
|
<p><img class="diagram" src="../../../../static/images/blog/2010/02/hg-branching-1-start.png" alt="Sample Repository"></p>
|
||
|
|
|
||
|
|
<p>In this example there's mostly just a single developer (you) working on the
|
||
|
|
project to add features, fix bugs, etc.</p>
|
||
|
|
|
||
|
|
<p>The repository is online so other people can get the code. They can add
|
||
|
|
features and fix bugs if they want, but it doesn't happen very often because
|
||
|
|
it's a small project.</p>
|
||
|
|
|
||
|
|
<p><strong>Note:</strong> I find it helpful to have graphs of the changesets in a repository
|
||
|
|
so I can see what's going on. If you want some nice, quick ASCII-art graphs of
|
||
|
|
your own repositories you can <a href="http://hgtip.com/tips/beginner/2009-10-03-stay-sane-with-graphlog/">use the graphlog extension</a>.</p>
|
||
|
|
|
||
|
|
<h2 id="s3-branch-setup"><a href="index.html#s3-branch-setup">Branch Setup</a></h2>
|
||
|
|
|
||
|
|
<p>In this workflow you don't do any up-front setup at all. Just use Mercurial as
|
||
|
|
you normally would, committing your changes along the way and pushing them to
|
||
|
|
somewhere where other people can get them (like <a href="http://bitbucket.org/">BitBucket</a>).</p>
|
||
|
|
|
||
|
|
<h2 id="s4-contributing-to-the-project"><a href="index.html#s4-contributing-to-the-project">Contributing to the Project</a></h2>
|
||
|
|
|
||
|
|
<p>Let's say someone else starts using your project and finds a bug. They go
|
||
|
|
ahead and fix the bug themselves and commit a changeset for the fix. They
|
||
|
|
could then push their copy of the repository to somewhere public (like their
|
||
|
|
own BitBucket account) and it would look something like this:</p>
|
||
|
|
|
||
|
|
<p><img class="diagram" src="../../../../static/images/blog/2010/02/hg-branching-1-other.png" alt="Contributor Repository"></p>
|
||
|
|
|
||
|
|
<p>Once their changes are somewhere public they can email you and say:</p>
|
||
|
|
|
||
|
|
<blockquote>
|
||
|
|
<p>Hey, I fixed a bug in your project.</p>
|
||
|
|
|
||
|
|
<p>The fix is changeset be3063198fea in my copy of your repository at
|
||
|
|
http://.../</p>
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<h2 id="s5-merging-changes-from-contributors"><a href="index.html#s5-merging-changes-from-contributors">Merging Changes from Contributors</a></h2>
|
||
|
|
|
||
|
|
<p>When you get an email like this you would head over to their repository and
|
||
|
|
take a look at the changeset. If you decide it's good and want to incorporate
|
||
|
|
it into your own repository it's as simple as running <code>hg pull
|
||
|
|
http://their/repo/</code>.</p>
|
||
|
|
|
||
|
|
<p>If you haven't made any new changes your repository would now look exactly
|
||
|
|
like theirs. You can update to the new tip and continue working as usual.</p>
|
||
|
|
|
||
|
|
<p>What if you've made changes between the time they cloned (or last pulled) your
|
||
|
|
repository and the time you read the email & pulled their changes? In that
|
||
|
|
case your repository will look like this after you pull from them:</p>
|
||
|
|
|
||
|
|
<p><img class="diagram" src="../../../../static/images/blog/2010/02/hg-branching-1-needs-merge.png" alt="Sample Repository Before Merging"></p>
|
||
|
|
|
||
|
|
<p>Because John's bugfix changeset and your refactoring changeset both have the
|
||
|
|
same parent there are now two "anonymous branches" in your repository. This
|
||
|
|
doesn't bother Mercurial at all — repositories can have as many "anonymous
|
||
|
|
branches" as you like.</p>
|
||
|
|
|
||
|
|
<p>You'll probably want to merge these branches, so you'd run <code>hg update
|
||
|
|
a2125cb20c54</code> (if you weren't already there) and then <code>hg merge be3063198fea</code>
|
||
|
|
to merge John's bugfix with your new changes. The result would look like this:</p>
|
||
|
|
|
||
|
|
<p><img class="diagram" src="../../../../static/images/blog/2010/02/hg-branching-1-after-merge.png" alt="Sample Repository After Merging"></p>
|
||
|
|
|
||
|
|
<p>Now you're back to having just one head and you can continue working as usual,
|
||
|
|
with John's changes and your changes all merged together.</p>
|
||
|
|
|
||
|
|
<h2 id="s6-summary"><a href="index.html#s6-summary">Summary</a></h2>
|
||
|
|
|
||
|
|
<p>This workflow is the simplest one possible. There's no up-front setup and it's
|
||
|
|
very easy for new people to contribute to the project — they just clone,
|
||
|
|
commit, push, and tell you about their changes. It's great for small projects
|
||
|
|
with one main developer and the occasional contributor.</p>
|
||
|
|
|
||
|
|
<p>If you have a project with a lot of people working together this can get
|
||
|
|
pretty chaotic. Your repository graph will end up looking like a tangled mess.
|
||
|
|
In that case you'll want a workflow with a bit more structure.</p>
|
||
|
|
|
||
|
|
<p>I'm planning on writing at least two or three more posts about some more
|
||
|
|
complicated branching workflows in the future. If you have any specific
|
||
|
|
examples you think I should write about please let me know!</p>
|
||
|
|
</article></main><hr class='main-separator' /><footer><nav><a href='https://github.com/sjl/'>GitHub</a> ・ <a href='https://twitter.com/stevelosh/'>Twitter</a> ・ <a href='https://instagram.com/thirtytwobirds/'>Instagram</a> ・ <a href='https://hg.stevelosh.com/.plan/'>.plan</a></nav></footer></body></html>
|