-
Notifications
You must be signed in to change notification settings - Fork 0
Branch Managment
Context : You want to create a new feature / fix a bug
Step 1 : create a new branch from dev named after what you want to do ex: feat/static_analysys/support_for_large_files
Step 2 : when the feature is implemented create a pull request to dev
Step 3 : ask for somebody to review your pull request
Step 4 : when your pr is approved take a look at the result of the github actions and advise what to do next
Commits should follow the git karma norm.
In the context of this project scope can be defined as what part of the project the commit is for:
- static analysys
- dynamic analysys
- gui
- ...
Production branch, represent the latest stable version of the project.
Every change to main should come with a version release.
No commits should ever be made on main.
- Integration test => blocking
- Performance test => blocking
- Security => blocking
2 reviews are required to validate a pr to main
Development branch, meant as a base to branch off for new feature development.
When the branch is stable and all the features of a milestone are implemented a merge on main should be done.
Commits on dev should be avoided as much as possible prefer making a feature or fix branch instead.
- Coding style => blocking
- Compilation => blocking
- Security => not blocking
1 review is required to validate a pr to dev
Used to create or fix a feature.
A branch should only contain one feature or fix, don't hesitate to create a lot of branches.
Commits should follow the git karma norm
- Coding style => not blocking
Used to patch a breaking bug or security issue on main.
When the fix is done, main should be merged into dev. This is the only time when main in merged into another branch.
- Coding style
- Compilation
- Security
When creating a new branch the name should be as follow :
<branch_type>/<scope>/<feature>