diff --git a/tp.md b/tp.md
index 7989d3082bbd23b0fdaf843ef1ef8c4061e618ea..daaf9e5273f3fa1258dde05a5d809fd541a54e5c 100644
--- a/tp.md
+++ b/tp.md
@@ -7,28 +7,28 @@ output:
     toc: true
     toc_depth: 3
     number_sections: true
+  html_document:
+    fig_caption: yes
+    theme: journal
+    toc: yes
+    toc_depth: 3
+    toc_float: true
     highlight: tango
-    latex_engine: xelatex
----
-
+latex_engine: xelatex
 ---
 
 # Setup your environment
 
-We are going to write some basic configuration files to be able to the
-[gitlab server of the LBMC](http://gitlab.biologie.ens-lyon.fr).
-If you are not using your own laptop, remember to delete your `~/.ssh` folder
-at the end of the TP. Otherwise, somebody else could use your ssh key if you
-don't protect them with a password.
-But don't stress to much about it, you can always remove the key later from your
-[gitlab configuration](http://gitlab.biologie.ens-lyon.fr/profile/keys).
+We are going to write some basic configuration files to be able to the [gitlab server of the LBMC](http://gitlab.biologie.ens-lyon.fr).
+If you are not using your own laptop, remember to delete your `~/.ssh` folder at the end of the TP.
+Otherwise, somebody else could use your ssh key if you don't protect them with a password.
+But don't stress to much about it, you can always remove the key later from your [gitlab configuration](http://gitlab.biologie.ens-lyon.fr/profile/keys).
 
 Throughout this practical, every string between chevrons `<like this one>` must be replaced with the adequate value.
 
 ## Git configuration
 
-Git can be configured with the `git config` command or directly by editing the
-`~/.gitconfig` file. Here is a config example to start:
+Git can be configured with the `git config` command or directly by editing the `~/.gitconfig` file. Here is a config example to start:
 
 ```sh
 # This is Git's per-user configuration file.
@@ -43,7 +43,7 @@ editor = vim
 co = checkout
 ci = commit
 st = status
-lo = log --graph --decorate --date-order --all"
+lo = log --graph --decorate --date-order --all
 lg = "log --pretty=format:\"%h - %an : %s\""
 lt = log --graph --oneline --all
 unstage = "reset HEAD"
@@ -52,13 +52,13 @@ unstage = "reset HEAD"
 You can replace `vim` by any other editor of your choice, like `nano` (easier to learn) or `gedit` (graphical).
 
 The **alias** section of the configuration is for shortcuts of git commands.
-`git checkout` is now equivalent to `git co` to minimize the number of key
-pressed.
+`git checkout` is now equivalent to `git co` to minimize the number of key pressed.
 
 ## Gitlab connection
 
-There are many ways to connect to a gitlab server. Git relies on other
-system protocols to handle authentication and rights. Here we are going to use two different method depending if you are using your laptop or a PSMN computer.
+There are many ways to connect to a gitlab server.
+Git relies on other system protocols to handle authentication and rights.
+Here we are going to use two different method depending if you are using your laptop or a PSMN computer.
 
 ### https method (for the PSMN computers)
 
@@ -73,8 +73,7 @@ git config --global http.sslVerify false
 For this method to work, you need to setup a password in you gitlab profile.
 Go to [https://gitlab.biologie.ens-lyon.fr/profile/password/edit](https://gitlab.biologie.ens-lyon.fr/profile/password/edit) and set your password.
 
-
-### `~/.ssh/config` file method (not for PSMN computers)
+### `~/.ssh/config` file method (for your personal computers)
 
 To connect to the gitlab server via ssh, you first need to generate a ssh key:
 
@@ -106,25 +105,26 @@ To test your connection run:
 ssh -Tv gitlab_lbmc
 ```
 
-With this second method, you will have to replace every `https://gitlab.biologie.ens-lyon.fr/` url in the sequel with `gitlab_lbmc:`. 
+With this second method, you will have to replace every `https://gitlab.biologie.ens-lyon.fr/` url in the sequel with `gitlab_lbmc:`, the shortcut you defined in your `~/.ssh/config` file. 
 
 # Part 1: Git alone
 
 Git is a powerful tool to keep track of changes in your project and to manage your modifications history.
 In this first part of the TP you will practice different git commands to keep track of your work and modifications with Git.
 
-## Your first git repository
+> A Git repository is an informatic project (folder) where changes are recorded using Git.
 
-### Creation of a git repository
+## Creation of a git repository
+
+Start by creating a folder `alpha` in which you are going to write your project:
 
-Start by creating a folder `alpha` in which you are going to write your project
 ```sh
 mkdir alpha
 cd alpha
 ```
 
-Once in the alpha folder, you can initialize a git repository.
-A git repository is a project tracked and indexed by git.
+Once in the alpha folder, you can initialize a Git repository.
+A Git repository is a project tracked and indexed by git.
 
 ```sh
 git init
@@ -133,11 +133,11 @@ ls -la
 
 The `git init` command create an hidden `.git` folder at the root of your project.
 You should not temper with the content of the `.git` folder.
-Everythings in the `.git` folder belong to git the rest of the `alpha` folder belong to you.
+Everythings in the `.git` folder belong to Git the rest of the `alpha` folder belong to you.
 
 When you issue `git` command the content of the `.git` folder is accessed or modified by git.
 
-### Using git to track changes
+## Using git to track changes
 
 There is nothing in our repository:
 
@@ -151,9 +151,9 @@ We defined `st` as an alias of `status` in the `~/.gitconfig` file, so the two c
 Our first code:
 
 ```sh
-mkdir src
+mkdir data
 git st
-echo 'a' > src/dict.txt
+echo 'a' > data/letter.txt
 git st
 ```
 
@@ -164,31 +164,67 @@ There are *untracked files*.
 To start tracking file we use the command `git add` :
 
 ```sh
-git add src/dict.txt
+git add data/letter.txt
+ls -R .git/objects/
 git st
 ```
 
-There are now changes to be committed, this means that git is now following the state of the `src/dict.txt` file.
-The current state of `src/dict.txt` is recorded.
+> `git add` greate *git blob*:
+>
+> - contains the compressed content of a file
+> - The name of the blob is the [SHA1](https://en.wikipedia.org/wiki/SHA-1) of the file.
+> - The first two characters of the [SHA1](https://en.wikipedia.org/wiki/SHA-1) are used as the name of a directory inside the objects folder
+> - The rest of the hash is used as the name of the blob file
+
+There are now changes to be committed, this means that git is now following the state of the `data/letter.txt` file.
+The current state of `data/letter.txt` is recorded.
+
+![git add made a copy of the a file creating the corresponding blob](img/staging_1.png){height=150px}
 
 ```sh
-echo 'b' > src/dict.txt
+echo 'b' > data/letter.txt
+ls -R .git/objects/
 git st
 ```
 
-We changed the state of `src/dict.txt`, but those changes are not staged for commit.
-The previous states of `src/dict.txt` is still recorded *somewhere* even if it differs from its current state.
+We changed the state of `data/letter.txt`, but those changes are not staged for commit.
+The previous states of `data/letter.txt` is still recorded *somewhere* even if it differs from its current state.
 
 This *somewhere* is called the staging area (where you stage changes).
 
+![modifications in the working area don't affect what's stored in Git](img/staging_2.png){height=150px}
+
+```sh
+git ls-files --stage
+printf '1234' > data/number.txt
+git add data/number.txt
+git ls-files --stage
+printf '1' > data/number.txt
+git add data/number.txt
+git ls-files --stage
+```
+
+![The staging area is different from the working directory](img/staging_3.png){height=150px}
+
+
 You can save the state of the staging area definitively with the command `git commit`
 
 ```sh
-git commit -m "a: my first commit"
+git commit -m "a1"
 git st
 ```
 
-You cleared the change to be committed and wrote them in a commit.
+Here "a1" is the message associated with the commit.
+
+![Write clear and informative commit messages ([xkcd](https://xkcd.com/))](img/git_commit_xkcd.png){height=250px}
+
+> There are two rules for committing:
+>
+> - Commit often
+> - Write clear and informative logs
+> [http://git-scm.com/book/ch5-2.html](http://git-scm.com/book/ch5-2.html)
+
+You cleared the changes to be committed and wrote them in a commit.
 
 ```sh
 git log
@@ -196,25 +232,40 @@ git lo
 ```
 
 You wrote your first commit with an unique identifier:
-`c7a4cb9c7665b422081794402155af9dcfdbeab1`
+`8afd9d3fef28f7a9d582c9fa11d3702a9161feb4`
+
+> `git commit`:
+> - creates a tree graph to represent the content of the version of the project being committed
+> - creates a commit object
+> - points the current branch to the new commit object
+
+```sh
+git ls-tree -r 8afd9d3fef28f7a9d582c9fa11d3702a9161feb4
+git ls-tree -d 8afd9d3fef28f7a9d582c9fa11d3702a9161feb4
+```
+
+The `8afd9d3fef28f7a9d582c9fa11d3702a9161feb4` point to the tree object with point to the two committed files.
+
+[The commit a1 record the tree structure and the files corresponding to the staging area](img/commit_a1.png){height=150px}
 
 In git, there are 3 areas:
 
 - The working area (everything in `alpha/` except the folder `.git`)
-- The staging area
-- The repository
+- The staging area (in the `.git` folder)
+- The repository (also in the `.git` folder)
 
-![git areas](img/three_git_areas.png)
+![git areas](img/three_git_areas.png){height=250px}
 
 The repository is a chain of commit beginning with your first commit.
 
 ### Navigating a git repository
 
-Let's create a new commit with the changes made to `src/dict.txt`:
+Let's create a new commit with the changes made to `data/number.txt`:
 
 ```sh
-git add src/dict.txt
-git commit -m "b: my second commit"
+echo "2" > data/number.txt
+git add data/number.txt
+git commit -m "a2"
 git st
 git lo
 ```
@@ -224,23 +275,25 @@ You have a second point in your commit history.
 You can navigate to a given point of the repository with the command `git checkout`:
 
 ```sh
-cat src/dict.txt
-git checkout c7a4cb9
-cat src/dict.txt
+git log
+cat data/number.txt
+git checkout 8afd9d3
+cat data/number.txt
 ```
 
-You don't have to give the complete commit identifier for the command `git checkout`, only an unique subset of it.
-The state, of the file `src/dict.txt` is back to the one at the time of the first commit.
+> You don't have to give the complete commit identifier for the command `git checkout`, only an unique subset of it.
+
+The state, of the file `data/number.txt` is back to the one at the time of the first commit.
 The `git checkout` or `git co` command rewrite your whole working area to match the state of the targeted commit.
 
 ```sh
-git lo
+git log
 ```
 
-The `git lo` command don't display your second commit anymore.
+The `git log` command don't display your second commit anymore.
 Git commits only know of their direct ancestor(s).
 
-The other change is in the first line of the `git lo` command:
+The other change is in the first line of the `git log` command:
 `(HEAD -> master)` became (HEAD).
 This change mean that you are in a *detached HEAD* state , the command `git st` also gives you this information.
 
@@ -297,8 +350,8 @@ git lo
 ```
 
 ```sh
-echo '1' > src/num.txt
-git add src/num.txt
+echo '1' > data/number.txt
+git add data/number.txt
 git commit -m "1: first commit in dev"
 git lo
 ```
@@ -307,15 +360,15 @@ If we have two branches `dev` and `master`, it's hard to tell them apart (`maste
 
 ```sh
 git co master
-echo 'c' > src/dict.txt
-git add src/dict.txt
+echo 'c' > data/letter.txt
+git add data/letter.txt
 git commit -m "c: third commit in master"
 git lo
 ```
 
 Congratulation you have a fork in your git repository !
 
-Lets make another one called `dict` from the branch `master` where `src/dict.txt` contain the letter `d`.
+Lets make another one called `dict` from the branch `master` where `data/letter.txt` contain the letter `d`.
 
 ### Merging branches
 
@@ -366,11 +419,11 @@ git lo
 ```
 
 The new commit is a `Merge` commit with the identifiers of its two ancestors.
-Here, we didn't have any conflict: in the `dev` branch, we worked on the `src/number.txt` file while in the `master` branch, we worked on the `src/dict.txt` file.
+Here, we didn't have any conflict: in the `dev` branch, we worked on the `data/numberber.txt` file while in the `master` branch, we worked on the `data/letter.txt` file.
 
 Let's complicate things !
-Create a new commit in the `master` branch where the content of `src/dict.txt` is set to `e`.
-Then create a new commit in the `dev` branch where the content of `src/dict.txt` is set to `f` and go back the the branch `master`.
+Create a new commit in the `master` branch where the content of `data/letter.txt` is set to `e`.
+Then create a new commit in the `dev` branch where the content of `data/letter.txt` is set to `f` and go back the the branch `master`.
 
 ```sh
 git branch
@@ -378,35 +431,36 @@ git merge dev
 git st
 ```
 
-The automatic merge fail due to a conflict in `src/dict.txt`.
+The automatic merge fail due to a conflict in `data/letter.txt`.
 You are now in a merging state.
-You must solve the conflict by editing `src/dict.txt`.
+You must solve the conflict by editing `data/letter.txt`.
 
-You can see three things in the `src/dict.txt`:
+You can see three things in the `data/letter.txt`:
 
 - The state of the file in your current branch (*HEAD*)
 - The state of the file in the last common ancestor of the two branches
 - The state of the file in the merged branch (*dev*)
 
-Edit `src/dict.txt`, to set its content to `f`.
+Edit `data/letter.txt`, to set its content to `f`.
 Then complete the merge:
 
 ```sh
-git add src/dict.txt
+git add data/letter.txt
 git st
 git commit
 git st
 ```
 
-You now, know how to deal with the different kind of merge.
+You now, know how to deal with the different kind of merge
 
-## Cloning a git repository
+## Part 2: Git togetherdata
 
 We start by cloning an existing repository.
 `file_handle.py` is a small python script to handle the dating and the access to dated files in a format compatible with the [guide of good practices at the LBMC](http://www.ens-lyon.fr/LBMC/intranet/fichiers/bioinfo/good-practices.pdf).
 The `git clone <url>` command retrieves the whole history of a project and setup a working area based on the last point in this history.
 
 ```sh
+cd ~/
 git clone https://gitlab.biologie.ens-lyon.fr/LBMC/file_handle.git git_basis_tp1
 cd git_basis_tp1
 ls -l
@@ -417,6 +471,7 @@ this command has a huge number of formatting options.
 
 ```sh
 git log --graph --all
+git lt
 ```
 
 Git history is not necessarily linear. The bifurcations or branches are a useful
@@ -520,14 +575,11 @@ repository is called `origin`
 git push
 ```
 
-You don’t have permission to write to this repository (if you want to
-contribute to the file_handle project you can ask me later). To cope with this
-problem you are going to create your own remote repository for this project on
-the gitlab server.
+You don’t have permission to write to this repository (if you want to contribute to the file_handle project you can ask me later).
+To cope with this problem you are going to create your own remote repository for this project on the gitlab server.
 
-To do so, go to [http://gitlab.biologie.ens-lyon.fr/](http://gitlab.biologie.ens-lyon.fr/)
-and click on **new project**. You can give a name to your project (we are going
-to use `git_basis` in the following commands). Click on **Create project**.
+To do so, go to [http://gitlab.biologie.ens-lyon.fr/](http://gitlab.biologie.ens-lyon.fr/) and click on **new project**.
+You can give a name to your project (we are going to use `git_basis` in the following commands). Click on **Create project**.
 You end up on your project home page.
 
 The main information is in the **ssh** box containing a link to your