brouillon de workflow git

workflow_git.txt

Un bon workflow pour git serait le suivant :

- avoir tout le temps branche distante _master_ :
  * personne ne travaille directement dessus
  * les tests automatiques passent dessus
  * correspondant au code de production

- avoir tout le temps branche distante de développement _dev_ :
  * future branche _master_
  * développements en cours stable
  * les tests automatiques passent dessus aussi

- avoir une branche locale par fonctionnalité en cours de dev
(merge via git rebase voir plus bas)

- avoir une branche locale par bug (merge via git rebase voir plus bas) 

- partager des branches distantes peut entrainer des situations confuses 


En cas de bug sur la version en prod, on crée une branche locale depuis
le master on corrige et on merge soit directement sur le master
soit sur la branche de dev.

Pour les merge, la commande git rebase est adaptée pour garder
une arborescence plate (plus lisible) et pour éviter l'effet tunnel
(genre on ne committe pas assez dans cette branche de bug).
Elle permet aussi d'avoir des commits sur le master plus clair,
et de diminuer les problèmes pour les merges.

Il est nécessaire de supprimer les branches locales une fois les
merge/rebase effectuées.

Attention tout de même, l'utilisation de git n'est pas évidente
pour tout le monde (ne pas mettre en les mains de tout le monde)
et dès qu'il y a un soucis... cela peut-être difficile à récupérer. 

Workflow du rebase :
git checkout -b featurebranch

some changes

git rebase master
git checkout master
git merge featurebranch
git branch -d featurebranch

Je pense qu'il faut limiter le nombre de branches en cours en même temps.
Une branche distante ou locale devrait avoir une durée de vie de maximum 3/5 jours.

La configuration suivante permet de faire des rebase à chaque git pull afin de garder un historique plus linéaire:
git config --global pull.rebase true # git pull => git pull --rebase

Quelques tests peuvent être fait avec le simulateur.