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. 

ton workflow marche si tu fermes tes branches après merge/rebase, sinon c'est un peu le bazard

a voir (workflow que nous n'appliquons pas, mais qui me semble intéressant) : http://nvie.com/posts/a-successful-git-branching-model/

Tester ses modifs en local :

git add -i (rn mode interactif)
git commit
git stash

passer les tests

git pull
git push #si vert
git stash pop

David me dit :
«Très intéressant ton gist.
Jusqu'à il n'y a pas si longtemps ma référence était : http://nvie.com/posts/a-successful-git-branching-model/ .
Mais vu que je suis souvent seul sur les projets et que sur les projets où je ne suis pas seuls les gens ne sont pas très motivés par ce genre de pratique (peut-être parce qu'on n'est pas assez nombreux, toujours), je n'ai pas eu l'occasion de l'appliquer.

Ce que j'ai pu voir, c'est l'effet négatif du 'merge' qui pourrit l'historique. Donc je suis entièrement d'accord concernant l'usage du rebase.
Pour les branches de fonctionnalités, à moins qu'elles aient une durée de vie d'une journée grand maximum, je pense qu'il vaut mieux les pusher sur une branche distante que le serveur d'intégration continue pourra scruter (on peut dire à Hudson de scruter toutes les branches).

Mais, parce qu'il y a un "mais", je pense que les branches par fonctionnalités ne sont pas forcément la solution idéale. La nouvelle tendance, qui va bien avec le Continuous Delivery, c'est le "Branch by abstraction" (et/ou Feature Toggle).

Je t'ai mis quelques liens à ce sujet un peu plus bas. Un des phrases que j'ai lues et qui m'a convaincu est la suivante :

"Many development teams are used to making heavy use of branches in version control. Distributed version control systems make this even more convenient. Thus one of the more controversial statements in Continuous Delivery is that you can’t do continuous integration and use branches. By definition, if you have code sitting on a branch, it isn’t integrated"

En gros, plutôt que de faire des modifications sur une branche, travaille directement sur le master mais n'active tes changement qu'une fois que ta fonctionnalité est terminée.
Ainsi :

• tu ne casses pas le master (ou dev dans ton cas) car tes tests valident que l'appli fonctionne correctement
• tu t'assures que l'effort d'intégration final est minimal (un "booléen" à changer plutôt qu'un merge à effectuer)

Ca demande une infrastructure afin de supporter l'activation / désactivation de fonctionnalité mais je pense que le jeu en vaut la chandelle.

Il y aura probablement toujours des cas où les branches seront la seule alternative viable, mais je pense que c'est une bonne idée de chercher à minimiser le nombre des cas où ça se produit.

Après, je dis ça, mais je n'ai pas expérimenté :)
En théorie, je trouve l'idée intéressant en tout cas.

Quelques articles sur le sujet :
http://pauljulius.com/blog/2009/09/03/feature-branches-are-poor-mans-modular-architecture/
http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-branches/
http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/
http://martinfowler.com/bliki/FeatureToggle.html
»

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.