Git-Workflow.md

-If you are completely new to Git and GitLab, start from reading the [Git Basics](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics) 
-or maybe [A Simple Guide to Git](http://rogerdudler.github.io/git-guide/).
+If you are completely new to Git and GitLab, start from reading the [Git Basics](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics) or maybe [A Simple Guide to Git](http://rogerdudler.github.io/git-guide/).
 
 Also you can check these:
+
 - [Interactive Git Tutorials](https://www.katacoda.com/courses/git/)
 - [Git History Visualizer](https://git-school.github.io/visualizing-git/#rewritten-history)
 
@@ -16,27 +16,25 @@ First of all, a few things about this repo:
 
 ## Our Branching Model
 
-*This branching model was inspired by <http://nvie.com/posts/a-successful-git-branching-model/>.*
+In Boardcore there is **main branch**:
 
-In Boardcore there are two **main branches**: 
+- The `main` branch: is the main branch, everything's that here has been tested and it's working (or at least it should).
 
-- The `master` branch: is the main branch, everything's that here has been tested and it's working (or at least it should).
+---
 
-------------------
-**:warning: WARNING: You should NEVER commit directly to the master**
+**:warning: WARNING: You should NEVER commit directly to the main**
 
------------------
+---
 
 To make changes to the software you should use **temporary branches**, such as:
 
-- `development` branches: are branched off from `testing` and exist for a limited amount of time for developing a specific feature (e.g. `somesensor-dev`). 
-- `hotfix` branches: when a bug is found on the master, a branch is created to find a fix to that bug.
-When the problem is solved, the branch will be merged with the master *and* the testing branch before being cancelled.
+- `development` branches: are branched off from `main` and exist for a limited amount of time for developing a specific feature (e.g. `somesensor`).
+- `hotfix` branches: when a bug is found on the master, a branch is created to find a fix to that bug. When the problem is solved, the branch will be merged with the master _and_ the testing branch before being cancelled.
 
 ### Branch Workflow
 
 - A new feature is required (e.g. a barometer driver)
-- A new branch called `barometer-dev` is created from `testing` (you can do it locally)
+- A new branch called `barometer-dev` is created from `main` (you can do it locally)
 
 ```
 git pull
@@ -44,26 +42,28 @@ git checkout -b barometer-dev
 ```
 
 - Commits are made on the branch
+
 ```
 <modify files>
 git status
 git add name-of-modified-file
 git commit -m "[BAROMETER] Added barometer driver."
 ```
-- Frequently `git pull` and `git rebase testing` (or merge) to keep aligned to the testing branch.
-- When it's ready, make sure it's 0 commits behind testing and **TEST** it one last time.
-```
-python sbs -v
-```
-- Make a `merge request` to merge the branch back into the testing branch
-- In `testing`, further integration tests occur and then everything is merged on the master
+
+- Frequently `git pull` and `git rebase main` (or merge) 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 another branch** and 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.
 
 ## Commits
-Commits are the core of your team work, because they are the way in which you communicate to the team
-how you changed the code. 
-For this reason, you have to *think* before you commit, and try to write [good commit messages](https://github.com/erlang/otp/wiki/writing-good-commit-messages).
+
+Commits are the core of your team work, because they are the way in which you communicate to the team how you changed the code. For this reason, you have to _think_ before you commit, and try to write [good commit messages](https://github.com/erlang/otp/wiki/writing-good-commit-messages).
 
 Some simple rules:
+
 1) Write **meaningful commit messages**, with a short explanation on the top and a more specific one under:
 
    ```
@@ -73,25 +73,25 @@ Some simple rules:
    ```
 
    For example
+
    ```
    [Wiki] Add Git Workflow page
-
+   
    The page contains the description of our workflow with git, in particular:
    - Basics(pull, add, commit, push)
    - Branching(master, testing, development and hotfixes)
    - Commits(how to write commit messages and when to commit)
    ```
-   Do this, and everyone will love you - including yourself, when you'll read 
-   your code after a month from when you last wrote it..
 
+   Do this, and everyone will love you - including yourself, when you'll read your code after a month from when you last wrote it..
 2) **One task = One commit**
 
-   Group together in the same commit the changes that were made for the same task: 
-   if you're about to write something like
+   Group together in the same commit the changes that were made for the same task: if you're about to write something like
+
    > Fixed bug in Class.cpp and Added something else in another Class.cpp
 
    Think twice! Probably you should be doing two separate commits.
 
-What's Next
------------
+## What's Next
+
 Now that you know how to work on this repository, you can read the [Coding Guidelines](Coding-Guidelines).
\ No newline at end of file