Git workflow

General git workflow

1. Name things properly: Issues, PRs, commit and branches will always be named using imperative present (ex. "Add a time field to booking process")
2. Keep it tidy: Issue will be tagged and sorted:

• If the issue is a new feature or an enhancement, tag it with feature.
• If the issue is a bug, tag it with bug.
• If the issue is cosmetic or translation (label) related, tag it with trivial.
• Apply the frontend and backend tags accordingly.
• Apply a priority: urgent, regular (no tag), not urgent or wontfix.
• Assign somebody to the issue if possible.
• Add it to the project. If it's a (urgent) bug or a trivial, add it to next. Otherwise (non-urgent/wontfix bug or feature), add it in backlog.

3. Know where to test: Two branches will be constantly connected to a server. The master branch is the version currently in production. staging contains the development version. Each are connected to an Heroku "dynos". A third dynos is floating and can be connected to a development branch
4. Use branches: Each feature or bug issue will be worked on a separate branch. The branch will be named with the name of the issue, in low caps, hyphenated (ex. add-a-time-field-to-booking). If the issue is a bug, derive it from master and prefix it with hotfix-. If the issue is a feature, create and merge with staging. If the issue is trivial, commit directly on staging (or master if it's urgent).
5. Plan your launch: For each launches, select issues that will be added to the next column. Create a launch PR and add the issues to a new milestone. Create a column at the extreme right with the launch name.
6. Let other knows: Once you start working on an issue (that have been assigned to you), apply the ongoing tag. Move it to the ongoing column.
7. Commit clearly: Each commits will contain a summary of what have been done, followed by the issue reference (ex. Add a time field into booking form #21).
8. Fix issues: Once the issue have been fixed:

• If the issue is trivial, close the issue and add a message on the launch PR.
• If the issue is a bug, create a PR to merge your hotfix- branch to master.
• If the issue is a feature, create a PR to merge your branch to staging.
• Remove the ongoing tag and move the issue to staged column on the project board.
• Ask somebody else to validate your work (see next point).
• Close the issue with a message tagging a validator.

9. Always double-check: To validate somebody else's work:

• Check on mobile and on desktop if the issue have been correctly fixed.
• If everything is correct, move the card to accepted column.
• If the issue isn't fixed, re-open the comment clearly what the problem is and what is the desired result. Move the card to have issues column.
• Merge (or express approval in) the corresponding PR if needed. Move the card to the launch column.

10. Launch the new version: After all issues of the milestone have been accepted, double-check that every issues have been correctly fixed, merge the staging PR and close the milestone. Move the cards from approved to the launch column. Archive the launch column.