| ... | ... | @@ -5,6 +5,7 @@ title: Developer guide |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# IMPORTANT
|
|
|
|
|
|
|
|
If you have a local clone of the repository that **predates Feb. 19th, 2025, you must absolutely make a new clone**.
|
| ... | ... | @@ -70,7 +71,7 @@ Must merge back into: |
|
|
|
Branch naming convention:
|
|
|
|
`<issue number>-hotfix-*` (automatically generated through the issue > create branch workflow, see [branching workflow](#branching-workflow))
|
|
|
|
|
|
|
|
#### Feature branches
|
|
|
|
##### Feature branches
|
|
|
|
> Feature branches are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).
|
|
|
|
>
|
|
|
|
> Source : https://nvie.com/posts/a-successful-git-branching-model/
|
| ... | ... | |
