Git-Workflow.md

@@ -15,7 +15,7 @@ which are different versions of the same project that can be `merged` into each
 6) `merge`: add all the changes in a branch to another branch (can produce `merge conflicts` when the same file has been modified in different ways: you have to resolve them in order to merge).
 7) `pull request`: ask for your branch to be merged with the original branch (it's better if you add some `reviewers` to check that everything's ok before merging).
 
-### Branching
+### Boardcore Branches
 
 In Boardcore there are two main branches: 
 
@@ -31,12 +31,21 @@ 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:
 
 - `feature` branches: are branched off from `development` and exist for a limited amount of time for developing a specific feature. 
-When the feature is ready, the developer should open a *Pull Request* to merge the feature branch back to the developing branch.
 - `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 development branch before being cancelled.
 
 If you want to see a nice branching model example take a look at <http://nvie.com/posts/a-successful-git-branching-model/>.
 
+### Boardcore Workflow
+
+- A new feature is required (e.g. a barometer driver)
+- A new branch called `barometer` or `barometer-dev` is created from `development` (you can do it locally)
+- Commits are made on the branch
+- Frequently `rebase` (merge from development new changes that have been done there)
+- When it's ready, make sure it's 0 commits behind the master and *TEST* it one last time.
+- A `pull request` is made to merge the branch back into the development branch
+- In `development` 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. 
 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).
@@ -44,29 +53,31 @@ For this reason, you have to *think* before you commit, and try to write [good c
 Some simple rules:
 1) Write meaninful commit messages, with a short explanation on the top and a more specific one under:
 
-```
-[Topic] short message
-*Blank line*
-Long explanation
-```
+   ```
+   [Topic] short message
+   *Blank line*
+   Long explanation
+   ```
 
-For example
-```
-[Wiki] Add Git Workflow page
+   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, development, features 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..
+   The page contains the description of our workflow with git, in particular:
+   - Basics(pull, add, commit, push)
+   - Branching(master, development, features 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..
 
 2) One commit = One task. 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
-> Fixed bug in Class.cpp and Added something else in another Class.cpp
+   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.
+   Think twice! Probably you should be doing two separate commits.
 
 What's Next
 -----------