Méthode de travail avec Git

On adoptera une méthode particulière de travail (workflow) avec git. Cela a pour but de structurer le développement.

Il faut se rappeler que Git fonctionne avec un système de branche :

(master) # git checkout -b newbranch
(newbranch) #

modifications...

(newbranch) # git add ...
(newbranch) # git commit -m "modifications"
(newbranch) # git checkout master
(master) #

(master) # git merge newbranch
(master) # git branch -d newbranch

Branche d'intégration : master/dev

Dans la branche master, rien ne doit être committé. Cette branche sert pour les releases. La branche dev elle fait office de branche d'intégration (intégration des fonctionnalités, des bugfix, des hotfix, ...).

Branche de fonctionnalités

Le développement d'une fonctionnalité se fait dans un branche issue de la branche dev :

(dev) # git checkout -b feature-mafeature
(feature-mafeature) #

modifications...
commits...

Une fois la fonctionnalité testée, et fonctionnelle, on l'intègre à la branche dev :

(feature-mafeature) # git checkout dev
(dev) # git merge --no-ff feature-mafeature
(dev) # git branch -d feature-mafeature
Si la branche a été pushé sur le remote :
(dev) # git push origin :feature-mafeature
```

``git merge --no-ff feature-mafeature``, ici le ``--no-ff`` permet de forcer la création d'un nouveau commit lors du merge.
Lorsqu'un merge à lieu, et qu'il n'y a aucun conflit, un **fast-forward** à lieu, et fusionne l'historique des deux branches. Mais lorsqu'il y a un conflit, un nouveau commit est créé contenant les modifications pour régler le conflit.

Ici, on veut forcer la création de ce commit (il sera donc vide s'il n'y a pas de conflit). Ainsi dans le graphique de l'historique on voit bien le début de la branche de feature, jusque son merge. On peut ainsi déterminer à partir de quelle intégration un bug a pu survenir.

## Branche de bugfix

De la même manière, lorsqu'un bug est présent, on créé une nouvelle branche afin de le fixer :

```console
(dev) # git checkout -b bugfix-monbugfix
(bugfix-monbugfix) #

modifications...
commits...

(bugfix-monbugfix) # git checkout dev
(dev) # git merge --no-ff bugfix-monbugfix
(dev) # git branch -d bugfix-monbugfix

Si une feature était en cours de développement :
(dev) # git checkout feature-mafeature
(feature-mafeature) # git merge dev
```

## Branche de release

Lors de la préparation d'une release, on créé une nouvelle branche, issue de la branche **dev** :

```console
(dev) # git checkout -b release-1.2
(release-1.2) #

modification du numéro de version
commit
```

Pour des bugfixs de dernière minute on les intègre comme d'habitude dans **dev** et on les merge dans la branche de release :

```console
(dev) # git merge --no-ff bugfix-monbugfix
(dev) # git checkout release-1.2
(release-1.2) # git merge --no-ff bugffix-monbugfix
(release-1.2) # git checkout dev
(dev) # git branch -d bugfix-monbugfix
```

Une fois la release prête à la distribution, on l'intègre dans la branche **master** :

```console
(release-1.2) # git checkout master
(master) # git merge --no-ff release-1.2
(master) # git tag -a 1.2
(master) # git checkout dev
(dev) # git merge --no-ff release-1.2
(dev) # git branch -d release-1.2
```

## Branche de hotfix

Il arrive qu'après la sortie d'une release, un bug intervient, un bug critique, devant être résolu immédiatement, on va donc créer une branche de hotfix issue de la branche **master**:

```console
(master) # git checkout -b hotfix-1.2.1
(hotfix-1.2.1) #

modifications...
commits...

(hotfix-1.2.1) # git checkout master
(master) # git merge --no-ff hotfix-1.2.1
(master) # git tag -a 1.2.1

(master) # git checkout dev
(dev) # git merge --no-ff hotfix-1.2.1
(dev) # git branch -d hotfix-1.2.1
```

## Conclusion

On a donc un développement structuré :

* la branche **master** est taggué à chaque nouvelle version (cela génèrera un archive **zip** et **tgz**, téléchargeable sur **github**), et ne contient que des merges ;
* la branche **master** ne contient que des versions stables ;
* la branche **dev** ne contient également que des merges des autres branches ;
* la branche **dev** contient un contenu stable, dans le cas contraire les bugfixs sont directement intégrés dans cette branche, elle possède également toutes les dernières features ;
* la branche **dev** n'est jamais corrompue par les features/bugfixs en cours de développement.