> For the complete documentation index, see [llms.txt](https://bakingtray.swcmicroscopy.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bakingtray.swcmicroscopy.com/general/developers/contributing-to-bakingtray.md).

# Contributing

Contributions to *BakingTray* are welcome.

* You should [fork the repository and send contributions as a pull request](http://thepilcrow.net/explaining-basic-concepts-git-and-github/) and 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 detailed help text like that in [stitchSection.m](https://github.com/SWC-Advanced-Microscopy/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, temporary functions, or highly specialised functions such as `BakingTray_forMyRigOnTuesdays.m`.
* Do not add your own INI files, recipe files, or other settings files. The `SETTINGS` and `SETTINGS_BACKUP` directories must be empty but for the `.gitignore` file.
* Use spaces instead of tabs for indenting.

## Branches

Development is distributed across two key branches:

* `master` - Finalised code ready to be shared with others. Must be stable. Merge into here from `dev`.
* `dev` - All development goes here for testing before merging into `master`.
* Feature branches. You may choose to work on your changes in a feature branch until ready to go into `dev`

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

* Check out `dev` and ensure it's up to date with `master`.
* 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.
* Run the system on `dev` for a time to ensure no regressions are present.
* Merge `dev` into `master` **with a merge-commit** to keep things neat in the master branch.