Re: Rrrr Zzzz

Je réfléchis à cette proposition et si ça intéresse quelqu'un j'envisage une série de journaux pour présenter différents workflows avec les tenants et aboutissants de ces choix.
Nous proposons 2 workflows dans ma boîte car 2 méthodes de projets coexistent (Une itérative à la RUP et une agile basée sur SCRUM).
Ils ne sont pas outillés car le but est de ne pas proposer de choses trop compliquées.

Notre workflow agile est très semblable à ce qui est proposé ici :
http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful
(Le 2ème post apporte des précisions utiles)

Les seules adaptations concernent:
1. Le suivi de la version en prod. On la marque par un tag qu'on déplace plutôt que par une branche
2. Les features branch:
Autant que faire se peut, on les décourage, mais à ceux qui souhaitent vraiment les mettre en oeuvre, on donne quelques consignes:
Qu'elles soient courtes et rebasées y compris sur le serveur de CI (elle sont propres à un seul developpeur). Le workflow ressemble alors à ce que décrit par Crev ici (rebase, push --force, revue éventuelle, merge --no-ff)
S'il s'agit d'epic et que l'on veut vraiment l'isoler dans une branche, il ne faut qu'il y en ait qu'une seule, que l'on réintègre depuis master à chaque commit (merge auto en CI qui casse le build si pb).

Sinon, si tu veux vraiment retrouver ton workflow à la SVN, hormis les 2 commandes de nos compères:

[alias]
 publish = !git commit --all && git push
 update = !git pull --rebase --autostash

Je verrais bien une commande intermédiaire qui te permet d'enregistrer ton travail en local régulièrement:

[alias]
 record = !git commit -all
 overwrite = !git commit -all --amend

et une pour le resolve après un update:

[alias]
 record = !git add