Git-commands.md

+## Sommaire <a name="sommaire"></a>
+- [Configuration Git](#config)
+- [Workflow Git](#workflow)
+    - [Nouvelle feature](#new-feature)
+    - [Correction de bug](#bugfix)
+    - [Correction critique sur master](#hotfix)
+    - [Déploiement nouvelle version](#MAJ)
+
+<a name="config"></a>
+## Configuration Git 
+
+Configuration obligatoire du `~/.gitconfig` :
+
+```ini
+[user]
+    name = Prénom Nom
+    email = prenom.nom@pasteur.fr
+[branch]
+    autosetuprebase = always
+```
+
+Alias utiles :
+
+```ini
+[alias]
+    co = checkout
+    st = status
+    ci = commit
+    br = branch
+    ds = diff --staged
+    unstage = reset HEAD --
+    amend = commit --amend --no-edit
+    lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=iso --branches --tags --remotes
+```
+[:arrow_up:](#sommaire) 
+
+<a name="workflow"></a>
+## Workflow Git 
+
+Le workflow se base sur [Git Flow](http://nvie.com/posts/a-successful-git-branching-model/) dans les grandes lignes. La branche `develop` contient les développements de la prochaine version, et `master` représente la version déployée sur le server Shinypro.
+
+<a name="new-feature"></a>
+#### Développement d'une nouvelle feature : 
+
+A faire sur develop !
+
+```bash
+$ git checkout develop
+$ git checkout -b feature/ma-nouvelle-feature
+... réaliser les développements
+$ git commit -a
+$ git push -u origin feature/ma-nouvelle-feature
+```
+
+Créer la Merge Request (banche feature/ma-nouvelle-feature -> develop dans GitLab. Référencer l'issue concernée dans le message de merge (en écrivant *issue #num-de-l'issue*)
+
+[:arrow_up:](#sommaire) 
+
+<a name="bugfix"></a>
+#### Correction de bug lié à une issue : 
+
+A faire sur develop !
+
+```bash
+$ git checkout develop
+$ git checkout -b bugfix/mon-bugfix 
+... réaliser les développements
+$ git commit -a
+$ git push -u origin bugfix/mon-bugfix 
+```
+
+Créer la Merge Request (banche bugfix/mon-bugfix -> develop dans GitLab. Référencer l'issue concernée dans le message de merge (en écrivant *issue #num-de-l'issue*)
+
+[:arrow_up:](#sommaire) 
+
+<a name="hotfix"></a>
+#### Hotfix : 
+
+Utilisé pour corriger rapidemment uetne erreur directement sur master, sans passer par develop.
+
+```bash
+$ git checkout master
+$ git checkout -b hotfix/mon-hotfix
+... réaliser les développements
+$ git commit -a
+$ git push -u origin hotfix/mon-hotfix
+```
+
+Créer la Merge Request associée dans GitLab. Une fois la branche mergée dans `master` il est possible de `cherry-pick` les commits sur `develop` par exemple :
+
+```bash
+$ git checkout develop
+$ git cherry-pick identifiantducommit1
+$ git cherry-pick identifiantducommit2
+$ git push
+```
+
+[:arrow_up:](#sommaire) 
+
+<a name="MAJ"></a>
+#### MAJ de master sur une nouvelle version (à déployer sur le server) : 
+
+Commencer par créer un tag sur **develop** lorsqu'une version satisfaisante pourrait être déployée
+
+```bash
+$ git checkout develop # (1)
+$ git merge master # pour être sûrs que develop dispose de tous les commits de master (2)
+# doit renvoyer "already up to date". Sinon, un commit de merge sera ajouté, avec de potentiels conflits.
+$ git tag # pour voir les tags existants
+$ git tag -a vx.x -m "stuart version x.x"
+$ git push origin develop --tags # (3)
+```
+
+Une fois que le déploiement est validé, on met à jour master sur le tag créé
+
+```bash
+$ git checkout master # on retourne sur master
+$ git merge --ff-only vx.x # on remonte master au niveau du tag en fast-forward (4)
+$ git push origin develop master --tags
+```
+
+```
+(1)
+master o   o develop
+       |   |
+       o   o
+        \ /
+         o
+         |
+
+(2)
+           o develop
+         / |
+        /  |
+master o   o
+       |   |
+       o   o
+        \ /
+         o
+         |
+
+(3)
+           o develop 
+           |
+           o vx.x
+           |
+           o
+         / |
+        /  |
+master o   o
+       |   |
+       o   o
+        \ /
+         o
+         |
+
+
+(4)
+           o develop 
+           |
+    master o vx.x
+           |
+           o
+         / |
+        /  |
+       o   o
+       |   |
+       o   o
+        \ /
+         o
+         |
+```
+
+**NB :** les tests doivent être faits après l'étape `(2)`, une fois que `develop` dispose de tous les commits de `master`.  
+Si une branche de hotfix doit être créée à partir de `master` créer la branche de hotfix à partir de ce point.
+
+**Impotant :** 
+
+- Toujours vérifier l'état di repository local avec `git lg` avant de les push sur le dépot distant.
+- Une fois une Merge Request est mergée sur gitlab, vérifier le graph en ligne avant de pull les mises à jour en local : en cas d'erreur de merge, on peut forcer un pushde la version local sur le repository distant pour "annuler" le merger (en cas d'erreur dans le choix des branches par ex) 
+
+[:arrow_up:](#sommaire) 
+ 
+[Go back to Home page](Home)
\ No newline at end of file