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.
<aname="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)
<aname="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)
<aname="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)
<aname="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)
