Git-Workflow.md

@@ -17,9 +17,9 @@ which are different versions of the same project that can be `merged` into each
 
 ### Boardcore Branches
 
-This branching model was inspired by <http://nvie.com/posts/a-successful-git-branching-model/>.
+*This branching model was inspired by <http://nvie.com/posts/a-successful-git-branching-model/>.*
 
-In Boardcore there are two main branches: 
+In Boardcore there are two **main branches**: 
 
 - The `master` branch: is the main branch, everything's that here has been tested and it's working (or at least it should).
 - The `testing` branch: is where development takes places. When a new feature is ready, it has to work with 
@@ -30,7 +30,7 @@ the rest of the code and then, only when everything's working, it can be merged
 
 -----------------
 
-To make changes to the software you should use:
+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.
@@ -48,21 +48,26 @@ 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 merge testing` 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.
-- A `pull request` is made to merge the branch back into the development branch
+- When it's ready, make sure it's 0 commits behind testing and **TEST** it one last time.
+```
+python sbs -v
+```
+- Make a `pull request` to merge the branch back into the testing branch
 - In `testing` futher integration tests occur, and then everything is merged on the master
 
 ### Commits
-Commits are the core of your team work, because they are the way in which you change the code. 
+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 meaninful commit messages, with a short explanation on the top and a more specific one under:
+1) Write **meaninful commit messages**, with a short explanation on the top and a more specific one under:
 
    ```
    [Topic] short message
@@ -82,7 +87,7 @@ Some simple rules:
    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 commit = One task. Not less, not more.
+2) **One task = One commit**. Not less, not more.
 
    Group together in the same commit the changes that were made for the same task: 
    if you're about to write something like