J'ai pas écrit de tests mais si quelqu'un casse quelque chose à l'avenir, faut le disputer parce que c'est mal de casser mon code. Le repository est incohérent mais faut disputer les devs qui ont pas utilisé le flag --no_incoherence_introduced_please
Normalement le développeur, avant de merger officiellement sur le dépôt, doit vérifier sur le merge fonctionne comme attendu (compile et que les tests unitaires tournent correctement). Voire un système d'intégration continue qui vérifie ces propriétés avant de pousser ça définitivement dans le dépôt commun.
Tu peux donner les outils que tu veux aux développeurs, s'ils ne vérifient pas (ou si aucun mécanisme dans l'intégration du code ne le fait) que son commit / merge n'apporte pas de soucis particuliers, je ne vois pas par quel miracle un outil pourrait tout résoudre. C'est quand même la base... Car bon, si le code ne compile pas, je n'ose imaginer s'il a vérifier qu'il n'y a pas eu de bogues / régressions ou autres introduits.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Renault (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 4.
Normalement le développeur, avant de merger officiellement sur le dépôt, doit vérifier sur le merge fonctionne comme attendu (compile et que les tests unitaires tournent correctement). Voire un système d'intégration continue qui vérifie ces propriétés avant de pousser ça définitivement dans le dépôt commun.
Tu peux donner les outils que tu veux aux développeurs, s'ils ne vérifient pas (ou si aucun mécanisme dans l'intégration du code ne le fait) que son commit / merge n'apporte pas de soucis particuliers, je ne vois pas par quel miracle un outil pourrait tout résoudre. C'est quand même la base... Car bon, si le code ne compile pas, je n'ose imaginer s'il a vérifier qu'il n'y a pas eu de bogues / régressions ou autres introduits.