The fundamental principle is that the MASTER branch must remain compilable at all times and should never contain incomplete developments.
The golden rule is that **MASTER SHOULD COMPILE AT ALL TIME** and does not
Development work on the master branch must be avoided. Instead, each feature or topic should have its own dedicated branch. Developers should create new branches as needed, and all work—including collaborative efforts—should occur within these topic-specific branches.
contain in-progress developments.
More precisely, development never happens on master: each topic should have
Before merging changes into master, ensure that your code:
its own branch (feel free to create one if needed) and work happens there,
even when several people are involved.
Once a set of changes (e.g. a new case study) is complete and polished enough
- Is complete and thoroughly tested
(comments, adequate identation, no use of generated hypothesis names, etc.),
- Contains clear and comprehensive comments
you may merge it to master by squashing its commits into meaningful pieces
- Features proper indentation
(only a few, usually one may be enough) or submit a pull request.
- Uses descriptive hypothesis names rather than auto-generated ones
- Meets all project quality standards
When your changes are ready (such as a completed case study), you have two options:
1. Submit a pull request for review
2. Merge directly into master after squashing your commits into meaningful, well-organized units (typically one or a few commits that clearly represent the changes)
