#summary Useful hints for contributing code to Hedgewars
*Table of Contents*
<wiki:toc max_depth="2" />
= Introduction =
You want to contribute code to Hedgewars? That's great! Here are some hints how to help us with importing your code.
= Recommended workflows =
== Using a mercurial clone ==
TODO
=== Creating a (named) branch ===
We prefer not to use (named) branches for little patches, as branches are permanent and will clutter the list of {{{hg branches}}}.
So for small code contributions, use unnamed branches instead (see below).
However, if you are going to write code that is more a pro#summary Useful hints for contributing code to Hedgewars
*Table of Contents*
<wiki:toc max_depth="2" />
= Introduction =
You want to contribute code to Hedgewars? That's great! Here are some hints how to help us with importing your code.
= Recommended workflows =
== Using a mercurial clone ==
TODO
=== Using (named) branches ===
Branches are alternative commit histories. Changes done in one branch can be merged into other branches as needed.
Most main development happens on the main repository branch "default".
We prefer not to use separate branches for little patches, as branches are permanent and will clutter the list of {{{hg branches}}}.
So for small code contributions, use "unnamed branches" instead (see below).
However, if you are going to write code that is more a project than a patch and that will take dozens of commits, feel free to do that work on a new branch.
To create a new branch use {{{hg branch}}} followed by the name of the new branch, before committing the first code.
=== Using unnamed branches ===
_Unnamed branches_ a.k.a. _topological branches_ happen when the history of commits within a branch (e.g. "default") splits up into alternative commits chains.
These alternative chains will have more than one {{{head}}} (at the the end of each chain) within the same branch, until they will be merged back together into a single chain.
*In order for us to be able which bugfixes/features of you we merge into the official repository, you should put each in a separate _unnamed branch_ as described above.*
Make sure that the first commit of each bugfix/feature commit set is based on a commit from the official repository, that way your bugfixes/features will not depend on the commits of each other and can be merged into official individually, as needed.
That means: *Before you start writing code towards a new bugfix/feature, make sure to {{{hg update}}} to a revision from the official repository.*
In newer versions of Mercurial you can give those unnamed branches a "local" and removable name using {{{hg bookmark}}}.
*You can see example of how unnamed branches and bookmarks are used best [http://hg.hedgewars.org/hw-example-clone/graph HERE]*