Best practices

• If you're interested in contributing to developing the GUI, you'll need a GitHub account. After that's set up, you should fork the open-ephys/plugin-GUI repository. Once you've made your changes, submit a pull request to have them merged into the master branch. We will take a look at what you've done and decide whether we want to include it. Try to keep your repository up-to-date by running `git fetch upstream` and `git merge upstream/master` at least once a day (you'll have to type `git remote add upstream https://github.com/open-ephys/plugin-GUI.git` once to specify the location of the original repository). That way, you won't be working on code that's already obsolete.
• Branch early, branch often. Once you realize how branching works in git, you'll wonder how you ever lived without it.
• All commit messages should be written in the present tense. For example, you should write `git commit -m "Add new files"`, instead of `git commit -m "Added new files"`. We haven't always been careful about this, but we're trying to do a better job of it.
• If you've changed anything major, make your commit messages as thorough as possible. Here are some style guidelines you should adhere to.
• GitHub offers desktop applications for Windows and Mac, but we don't recommend using them. It's well worth learning how to use git from the command line.

Tips and tricks

• Type "t" anywhere in the GitHub code pages to activate a search function. It works amazingly well! Probably better than anything on your desktop. (Hit space to get out once you're finished).
• Git aliases are a great way to save time. A really handy one is `git config --global alias.s "status -s"`

GitHub branches

Since the GUI is in a state of continuous development, to be able to both provide a stable version of the GUI while improving and adding features, we've created three different working branches on github. Al pull requests must adhere to the policies of each one:

• Development branch: This branch is where most of the development will be done in this branch so, as such, any pull request can be performed into this one.
• Testing branch: Any time the development branch is in a seemly stable state, and specially before pulling or committing any big change, the contents of the development branch will be merged into the testing one. The only commits allowed for this branch are those that do not add any new features to the GUI, but improve or fix the existing ones.
• Master branch:The aims of this branch are stability and compatibility. Both the core GUI and plugins contained in this branch are guaranteed to be compatible with the ones in the most recent numbered version, available in the binary releases. Only code that is allowed to be merged into this branch is, then, fixes to already present functionalities which do not alter the plugin API in any way. Every time a new numbered version is released, the code from the testing branch will be pulled here and new binaries will be created.

For maintaining code coherency, every time there is a change in the Master branch, its contents will be merged into both Testing and Development. The same way, if there are changes merged into Testing, this branch will also be merged into Development. This assures that all commits in Development are always ahead of Testing and all in Testing are always ahead of Master, but never at the inverse.

In the case of plugin development, we actively encourage developers to maintain their own repositories and publish them in the relevant wiki page.This way their plugins can be easily developed and distributed without having to adhere to our release cycles.