diff --git a/tp.md b/tp.md
index 3d2a1df83e97617b1ea0ca8399abe6b5707088ba..dd76b6e431927a97200d564e1a03d1e36dfef78c 100644
--- a/tp.md
+++ b/tp.md
@@ -43,11 +43,14 @@ editor = vim
 co = checkout
 ci = commit
 st = status
-lo = log --graph --decorate --date-order
-lg = "log --pretty=format:\"%h - %an : $s\""
+lo = log --graph --decorate --date-order --all"
+lg = "log --pretty=format:\"%h - %an : %s\""
+lt = "git log --graph --oneline --all"
 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.
@@ -107,21 +110,235 @@ With this second method, you will have to replace every `https://gitlab.biologie
 
 # 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.
+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
+
+### Creation of a git repository
+
+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.
+
+```sh
+git init
+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.
+
+When you issue `git` command the content of the `.git` folder is accessed or modified by git.
+
+### Using git to track changes
+
+There is nothing in our repository:
+
+```sh
+git status
+git st
+```
+
+We defined `st` as an alias of `status` in the `~/.gitconfig` file, so the two command are equivalent.
+
+Our first code:
+
+```sh
+mkdir src
+git st
+echo 'a' > src/dict.txt
+git st
+```
+
+Git don't track folders, only files. For git folders are just structures to organise files.
+With the creation of `dict.txt` git is aware of a change in the repository.
+There are *untracked files*.
+
+To start tracking file we use the command `git add` :
+
+```sh
+git add src/dict.txt
+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.
+
+```sh
+echo 'b' > src/dict.txt
+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.
+
+This *somewhere* is called the staging area (where you stage changes).
+
+You can save the state of the staging area definitively with the command `git commit`
+
+```sh
+git commit -m "a: my first commit"
+git st
+```
+
+You cleared the change to be committed and wrote them in a commit.
+
+```sh
+git log
+git lo
+```
+
+You wrote your first commit with an unique identifier:
+`c7a4cb9c7665b422081794402155af9dcfdbeab1`
+
+In git, there are 3 areas:
+
+- The working area (everything in `alpha/` except the folder `.git`)
+- The staging area
+- The repository
+
+![git areas](img/three_git_areas.png)
+
+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`:
+
+```sh
+git add src/dict.txt
+git commit -m "b: my second commit"
+git st
+git lo
+```
+
+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
+```
+
+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.
+The `git checkout` or `git co` command rewrite your whole working area to match the state of the targeted commit.
+
+```sh
+git lo
+```
+
+The `git lo` 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:
+`(HEAD -> master)` became (HEAD).
+This change mean that you are in a *detached HEAD* state , the command `git st` also gives you this information.
+
+```sh
+git st
+```
+
+In git commit are chained one after another starting with the first commit.
+Therefore, you can always go back in the commit history.
+
+The repository, is not only made of commit but also of labels.
+Labels point to a commit and can be the target of the `git co` command.
+They are two types of labels:
+
+- branches
+- tags
+
+If the first commit is the root of a growing tree of commits, branches are the leafs of the tree.
+They change after each commit from pointing to the ancestor of the new commit, to pointing to the new commit.
+The default branch in git is called `master`
+Contrary to branches tags are anchored to a fixed commit.
+*HEAD*, is a special label that indicate your position in the tree of commit.
+
+You can add a tag to your first commit with the command `git tag`
+
+```sh
+git tag -a v0.1 -m "my version 0.1"
+git tag
+git lo
+```
+
+You now have one tag in your repository.
+The commit `c7a4cb9` is pointed by the tag `v0.1`.
+
+```sh
+git co master
+git st
+git lo
+```
+
+We are back at the leaf of the git repository.
+
+### Growing the repository tree
+
+We only have one branch, the `master` branch in our repository.
+This mean that we only have one timeline in our history.
+In git, you can have as many branches as you want, to tests out things for example.
+
+The following command create the branch `dev` and move us (*HEAD*) to it.
+```sh
+git co -b dev
+git st
+git lo
+```
+
+```sh
+echo '1' > src/num.txt
+git add src/num.txt
+git commit -m "1: first commit in dev"
+git lo
+```
+
+If we have two branches `dev` and `master`, it's hard to tell them apart (`master` is shorter).
+
+```sh
+git co master
+echo 'c' > src/dict.txt
+git add src/dict.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`.
+
+### Merging branches
+
+When you are ready to incorporate your new code in your main branch you need to merge the branch containing the new code into your main branch.
+You can merge branch with the command `git merge`.
+This command is going to try to merge the targeted branch into the branch you are on (*HEAD*).
+
+
+
+
+
+
+
+
 
 ## Cloning a git repository
 
-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.
+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
 git clone https://gitlab.biologie.ens-lyon.fr/LBMC/file_handle.git git_basis_tp1
-git -c http.sslVerify=false clone https://lmodolo@gitlab.biologie.ens-lyon.fr/LBMC/file_handle.git git_basis_tp1
 cd git_basis_tp1
 ls -l
 ```
@@ -281,8 +498,8 @@ git remote -v
 Then we use the following commands to push our local copy to our remote repository:
 
 ```sh
-git -c http.sslVerify=false push -u perso --all
-git -c http.sslVerify=false push -u perso --tags # tags need to be pushed separatly
+git push -u perso --all
+git push -u perso --tags # tags need to be pushed separatly
 ```
 
 ## merging branches
@@ -301,7 +518,7 @@ However, the reverse operation is possible:
 git checkout master
 git branch -v
 git merge tp1
-git -c http.sslVerify=false push perso
+git push perso
 ```
 
 You can see the graph of our modifications at the following address [http://gitlab.biologie.ens-lyon.fr/user_name/git_basis/network/master](http://gitlab.biologie.ens-lyon.fr/user_name/git_basis/network/master)
@@ -331,7 +548,7 @@ Clone **W**’s repository:
 
 ```sh
 git clone https://gitlab.biologie.ens-lyon.fr/<W_name>/git_basis.git git_basis_tp2
-git clone -c http.sslVerify=false https://gitlab.biologie.ens-lyon.fr/<W_name>/git_basis.git git_basis_tp2
+git clone https://gitlab.biologie.ens-lyon.fr/<W_name>/git_basis.git git_basis_tp2
 cd git_basis_tp2
 git remote -v
 git checkout -b tp2
@@ -360,7 +577,7 @@ git status
 Developer **C** is now ahead of `remote/master` by one commit.
 
 ```sh
-git -c http.sslVerify=false push
+git push
 ```
 
 The command is not working. Git writes a useful message giving you the right
@@ -373,7 +590,7 @@ get the last version of the project.
 
 ```sh
 git branch
-git -c http.sslVerify=false fetch perso
+git fetch perso
 git status
 git branch
 ```
@@ -408,7 +625,7 @@ While **W** is contributing to the redaction of the documentation, developer
 **C** continue to work on it:
 
 ```sh
-git -c http.sslVerify=false fetch
+git fetch
 git status
 ```
 
@@ -428,13 +645,13 @@ Then `file_handle.py` will return the absolute path to the last version of
 git add README.md
 git commit -m "README.md: add -f option description"
 git status
-git -c http.sslVerify=false push
+git push
 ````
 
 ## Developer **W**:
 
 ```sh
-git -c http.sslVerify=false push
+git push
 ```
 
 When **W** tries to push his modifications to the remote repository he has an
@@ -443,7 +660,7 @@ Git advise you to use the command `git pull`. We are not going to use this
 command and instead to:
 
 ```sh
-git -c http.sslVerify=false fetch
+git fetch
 git status
 git merge FETCH_HEAD
 ```
@@ -484,7 +701,7 @@ to complete the merge:
 ```sh
 git add README.md
 git commit
-git -c http.sslVerify=false push
+git push
 ```
 
 # Conclusion