Nicolas Ecarnot a écrit : > je ne souhaite pas que quelqu'un soit obligé de merger en central, et
> c'est pourquoi je préférerais que tout le monde ait le droit de
> pousser (est-ce une bonne idée ?).
Tu fais comme tu veux. L'un des avantages de git (et peut-être aussi une
des causes de sa complexité) est qu'il ne t'impose pas une façon de
travailler. C'est à chaque équipe de définir le « workflow » qui lui
convient. Pour une équipe qui est habituée à Subversion, il est tout à
fait naturel de permettre à chacun de pousser vers origin/master. De
même si tu peux faire confiance à chacun pour faire attention à ne rien
casser.
Pour un grand projet, avec beaucoup de contributeurs, la technique du
pull request est sans doute plus appropriée. Tu peux aussi l'utiliser
dans des petits projets si elle est dans la culture des différents
contributeurs. Mais il ne faut pas croire que c'est obligatoire.
> Actuellement, une fois que les modifs sont réalisées, l'utilisateur
> appelle un script de déploiement. Il me faudrait trouver une idée pour
> qu'un process - régulièrement - réalise un pull, puis appelle ce
> script de déploiement.
Je suggère d'utiliser un post-receive hook : l'action même de pousser
vers origin/master déclenche le script. Du « push to deploy » en somme.
Tu peux coupler ça à un pre-receive (ou update) hook qui lance le script
de test et refuse le push si le test ne passe pas.
