This page explains how to work as a team without fighting each other and with a minimum of QA...

Branches

On Github, the master branch contains the last stable version of the project, ie which is working for all the modules.

• For each backlog task (bug solving, implementation of a new functionality,...), create a new branch with an explicit name (ex: "bugfix-issue17" or "impl-HTTPS").
• For the pull requests (PR), see the following section.

In runtime, we should stay on master:

• When a PR is accepted, we try to switch as fast as possible to the runtime environment to check if the new version is working with it (there should be no problem if everything is set correctly...)
• If everything is then OK, we merge from the new branch to master on Github, we switch back to master with the runtime environment, and we pull the modifications to it.

Pulling a Request

1. Clone from Github to your local machine.
2. Do whatever is needed and commit with an explicit message. Push only on your copy of the repository.
3. Test locally, with the runtime version.
4. If it doesn't work, back to 2.
5. If enough interesting modifications has been done, launch a pull request. The PR must:

• have an explicit title (ex: not "fix old style" but "Tecursive protection - bug utf8 fixed" etc.)
• reference all the issues it solves
• precise that the local tests are OK, or it will be reverted.

6. The discussion is then open, so the other developers can check the code, the documentation, the correctness, how it is working on the production environment,...
7. If at least one developer has checked all this, she/he can do the merging. No auto-merge (why using PR then?)
8. Enjoy :)