Git-Workflow.md

@@ -28,7 +28,7 @@ To make changes to the software you should use **temporary branches**, such as:
 
 - `development (-dev at the end of the name)` branches: are branched off from `main` and exist for a limited amount of time for developing a specific feature (e.g. `somesensor-dev`).
 - `hotfix (-fix at the end of the name)` branches: when a bug is found on the `main`, a branch is created to find a fix to that bug (e.g. `somefix-fix`).
-- `update (-upd at the end of the name)` branches: when an update is needed, a branch is created to update the code (e.g. `someupdate-upd`). 
+- `update (-upd at the end of the name)` branches: when an update is needed, a branch is created to update the code (e.g. `someupdate-upd`).
 
 Once the coding is done, the branch will be merged and then deleted.
 
@@ -52,13 +52,18 @@ git commit -m "[BAROMETER] Added barometer driver."
 ```
 
 - Frequently `git pull` and `git rebase main` to keep aligned to the main branch.
-- When it's ready, make sure it's 0 commits behind main and **TEST** it one last time.
-- Make a `merge request` to merge the branch back into the main branch and set the current IPTL as the reviewer.
-- If some **issues** are open in the merge request, you will need to **solve** all of them before obtaining the approval from the reviewer.
-- In case you find an issue regarding a whole another topic, it would be best **opening an issue, another branch** and the corresponding merge request.
-- Temporary branches should be as "atomic" as possible. This means that the only connection that they have should be the main branch and **NOT** other temporary branches.
-- Once the code is ready and the reviewer likes it, contact your IPTL to approve the merge request.
-- Finally, when ready to merge 99% of the times you will need to squash (aggregate) the commits you made (to not fill the main branch history with minor details) but, if this is not the case and you need to leave more than one commit message, then you should refer to an interactive rebase.
+
+### Merge Requests
+
+When you have created the temporary branch and written the code you will need to follow these steps:
+
+* Make sure your branch is 0 commits behind main and **TEST** it one last time.
+* Make a `merge request` to merge the branch back into the main branch and set the current IPTL as the reviewer.
+* If some **issues** are open in the merge request, you will need to **solve** all of them before obtaining the approval from the reviewer.
+* In case you find an issue regarding a whole another topic, it would be best **opening an issue, another branch** and the corresponding merge request.
+* Temporary branches should be as "atomic" as possible. This means that the only connection that they have should be the main branch and **NOT** other temporary branches.
+* Once the code is ready and the reviewer likes it, contact your IPTL to approve the merge request.
+* Finally, when ready to merge 99% of the times you will need to squash (aggregate) the commits you made (to not fill the main branch history with minor details) but, if this is not the case and you need to leave more than one commit message, then you should refer to an interactive rebase.
 
 ## Commits
 
@@ -96,7 +101,7 @@ Some simple rules:
 
 ## **Interactive Rebase**
 
-**:warning: WARNING: You should NEVER try to rewrite the main branch history**
+**:warning: WARNING: Keep in mind that this is ADVANCED stuff and that you should NEVER try to rewrite the main branch history**
 
 ---