Sauf dans le cas d'un projet perso c'est clairement pas au VCS de faire ça.
Si tu fonctionnes par patch c'est à la phase en amont de faire ça (tu retrouves ce fonctionnement chez les projets Apache où un rapport sur les patchs attachés au BTS est généré. Comme ça tu peux décider de le merger ou de le raffiné en fonction de son score). Et dans tout les cas tu valides les branches en intégration continue.
Dans tout les cas le but étant de minimiser les problèmes avant et de les corriger rapidement après. Avoir une politique bête, méchante et binaire sur un hook de commit qui empêche d'avancer est souvent contre productive.
[^] # Re: Les warnings
Posté par ckyl . En réponse au journal compiler en c++ pour avoir plus de warnings. Évalué à 2.
Sauf dans le cas d'un projet perso c'est clairement pas au VCS de faire ça.
Si tu fonctionnes par patch c'est à la phase en amont de faire ça (tu retrouves ce fonctionnement chez les projets Apache où un rapport sur les patchs attachés au BTS est généré. Comme ça tu peux décider de le merger ou de le raffiné en fonction de son score). Et dans tout les cas tu valides les branches en intégration continue.
Dans tout les cas le but étant de minimiser les problèmes avant et de les corriger rapidement après. Avoir une politique bête, méchante et binaire sur un hook de commit qui empêche d'avancer est souvent contre productive.