# How to contribute

Contributions to *StitchIt* are welcome.

* Ideally you should [fork the repository and send contributions as a pull request](http://thepilcrow.net/explaining-basic-concepts-git-and-github/). 

  StitchIt tends to be updated regularly, so keep your fork up to date [or it will become difficult to merge your changes](https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request).
* New functions you add should have full help text e.g. like [stitchSection.m](https://github.com/SainsburyWellcomeCentre/StitchIt/blob/master/code/stitching/stitchSection.m)
* If you modify the arguments in an existing function you should also update the function's help text.
* Many small commits are better than single big ones.
* Keep your pull requests clean. e.g. do not include commented-out test code code, temporary functions, or highly specialised functions such as `stitchSection_BobsVersion.m`. That includes adding your INI files or your post-acquisition functions. Such pull requests won't be accepted. 
* Ideally use spaces instead of tabs for indenting. 
* Read the [developer notes](https://stitchit.mouse.vision/developers/developer-notes)

## Branches

Development is distributed across three branches:

* `master` - Finalised code ready to be shared with others. Must be stable. Merge into here from `prerelease`.
* `prerelease` - Tested code that can be run on a live system but may have bugs. Merge into here from `dev`.
* `dev` - All development goes here. Unstable.

You should keep the number of commits low on `master` and `prerelease`. The development cycle goes as follows.

* Check out `dev` and ensure it's up to date with `master` and `prerelease`.
* Make changes and commit to `dev`. 
* Perform basic tests. e.g. ensure no obvious bugs are present. Run any unit tests, should they be available, or write unit tests.
* List changes in the changelog. Assume the changelog will be read by users.
* Merge to `prerelease`  **with a merge-commit** to keep things neat. 
* Run the system on `prerelease` for a time to ensure no regressions are present. 
* Merge `prerelease` into `master` **with a merge-commit** to keep things neat in the master branch.