feat: rework gitflow

docs/ecolyo/technical/gitflow.md

@@ -2,44 +2,44 @@
 
 ## Protecting branches
 
-Protected branches prevent anyone to push on the selected branch, the only way to add code to the branch will be using merge requests.
+Protected branches prevents anyone from pushing. The only way to push on a branch is with **merge requests**.
 
-### Setting Development Branch
+## Branch naming
 
-- Retrieve the project on your computer, open a command line and execute.
+??? quote "Ancient naming convention with Icescrum"
 
-```sh
-git clone https://forge.grandlyon.com/web-et-numerique/factory/llle_project/ecolyo
-```
+    When we were using Icescrum, each User Stories (US) was identified by a number. In order to easily identify the commit that refers to the US, a `feature` branch name should follow this structure:
 
-## Start Developing
+    - _feat/USXX-<title_of_the_user_story\>_
 
-### Branch naming
+    You can create the branch by typing: `git checkout -b feat/USXX-<title_of_the_user_story>`
 
-:warning: to be updated with the changes of Factory
+    > Note that the **feat** type is the only one with a dedicated folder (feat/-US).
 
-In our team organisation we are using Icescrum to keep track of our User Stories (US). Each US is identified by a number. In order to easily identify the commit that refers to the US, a `feature` branch name should follow this structure:
+    Each fix branch should be named as the following _fix/<title_of_the_fix\>_.
 
-- _feat/USXX-<title_of_the_user_story\>_
+    You can create the branch by typing: `git checkout -b fix/-<title_of_the_fix>`
 
-You can create the branch by typing:
+With **Factory** process, we have issues listed on gitlab and we can create merge requests and branches from issues. The default branch name is the title of the issue. Try to **shorten** the branch name and translate it to **english**.
 
-```sh
-git checkout -b feat/USXX-<title_of_the_user_story>
-```
+!!! example "Example of branch naming"
+    Issue 299 named "_[Eau/ Elec/ Prix/Backoffice] Non prise en compte d'un nouveau prix/nouvelle date dans changement prix d'un fluide dans la modale estimation des prix_"
 
-> Note that the **feat** type is the only one with a dedicated folder (feat/-US).
+    The default branch name would be **`299-eau-elec-prix-backoffice-non-prise-en-compte-d-un-nouveau-prix-nouvelle-date-dans-changement`** which is quite long and not so convenient in your editor.
 
-Each fix branch should be named as the following _fix/<title_of_the_fix\>_.
+    Try to shorten by using **key words**, for example : **`299-latest-prices-in-estimation-modal`**
 
-You can create the branch by typing:
+## Merge requests
 
-```sh
-git checkout -b fix/-<title_of_the_fix>
-```
+!!! tip "Name you merge request with the desired conventional commit"
+    By naming your merge request the desired conventional commit, it will be easier when merging by clicking the "Edit commit message"
+
+Follow the `merge_request_template` when creating a merge request. Make sure to update it as you code to indicate the reviewer what changed and what is necessary to test.
 
+It is important that you **squash** your commits when merging. The box is checked by default. Make sure to use a **conventional commit**.
 
-### Conventional commit
+
+## Conventional commit
 
 The [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/#summary) is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.
 
@@ -61,6 +61,13 @@ The commit contains the following structural elements, to communicate intent to
 * types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
 * footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.
 
+!!! success "Respecting conventional commits"
+    By respecting conventional, you ensure that :
+
+    - the [changelog](https://forge.grandlyon.com/web-et-numerique/factory/llle_project/ecolyo/-/blob/dev/CHANGELOG.md) stays up to date
+    - the feature/fix you worked on is listed in the changelog
+
+    📝 While adhering to the conventional commit guidelines, you have the option to exclude specific commits from appearing in the changelog. To do so, use `chore(scope): message`.
 
 ## Gitflow Scheme