Demiurge Development Guidelines

General rules

1. Don't talk about the git club
2. Useful commit messages are required, (at least on master branches, or when merging to it)
3. Never commit directly to the master branch
4. Bug fixes should be done in the dev branch
5. New developments should be done in your own branch (branching from the dev branch)
6. When development is finished and your code is stable merge your branch into the dev branch
7. Make sure your commit history is clean before merge into the dev branch (git rebase -i is your friend)
8. After merging, delete any useless branch
9. The master branch will be updated regularly based on the dev branch

Branching structure

• The master branch of each repository should be considered to be "release ready", meaning that at every point in time it should compile without error, be well-documented and as bug-free as possible.
• The dev branch will be used to share common resources and bug fixes between us (internally). It should be kept as stable as possible (and once you are sure it is working correctly might be merged into the master branch).
• If you start developing a new feature (a new loop-function, new reference model, new features for the colored arena, etc.) you should branch of the dev branch. Whenever there are bug fixes (or other important commits on dev) you should merge the dev branch into your own branch (you should do this regularly as this will help you also in the future when you need to merge your branch back into the dev branch).
• Once your development is finished and you want to share your code with the rest of us (or a publication is approaching), merge your feature into dev. If you do this timely than the others can use your code for their experiments (and you don't need to solve merge conflict six months after you last touched the code). Before you do the merge, we would ask you to run a rebase (git rebase -i [COMMIT_HASH] to clean your commit history. Experience shows that many commits are not as nice as they can be (committing the same file in several subsequent commits, "helpful" commit messages like done, non-compiling commits to save your work at the end of the day).
• If the code in dev is stable enough, we will merge it into the master branch. From there you can create a "tag" or "release" in git which you can then reference from your paper.

Special case: AutoMoDe

The core project of AutoMoDe is a special case. Since we are doing many mutually exclusive changes to the controller and grammar we cannot merge our changes together. Instead we will keep a private repository in which we will develop. The master branch of this repository is similar to the dev branch of the other repositories. General bug fixes will be made here and you should update your own branches when changes are made in the master. For your own AutoMoDe version, you branch of master and develop your code. Once it is ready for publication, you will create a branch from master branch in the public AutoMoDe repository (give it a name related to your publication if possible). Copy your code from the private repository to the public one and commit it (in a single commit). This way also this code should be available for all researchers. Please still make sure that it is well documented, compiles without errors and is bug free (as much as possible).

Useful links

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

https://git-scm.com/docs/git-merge