L'invio di test non funzionanti / codice rotto al repository locale non è problematico in sé e per sé. I problemi iniziano a sorgere quando uno si impegna localmente in un ramo di integrazione appositamente designato in previsione di una spinta verso un repository centrale. I veri problemi sorgono quando si spinge cose rotte in un ramo appositamente designato su un repository centrale.
Un sistema che preclude completamente l'esecuzione di test non funzionanti è un sistema guasto. Se segui il mantra di scrivere i test prima di scrivere il codice, i test falliranno necessariamente all'inizio. Rendere impossibile commettere quei test intenzionalmente falliti non ha senso.
Un sistema che preclude completamente il commit di codice non funzionante è anche un sistema danneggiato. Gli sviluppatori possono iniziare con pseudo-codice che non si compila nemmeno, quindi passare al codice reale che non funziona e infine al codice reale che apparentemente funziona. Rendere impossibile commettere quelle idee iniziali non ha senso. Avere il mio codice rotto commesso sul mio repository locale ha salvato la mia parte posteriore più di una volta.
Rubare parole dallo Zen di Python, "La gestione della configurazione è una delle grandi idee - facciamolo di più!"
Tendo a lavorare in ambienti esoterici in cui è impossibile eseguire test locali completi (ad esempio, supercomputer, reti di potenti non supercomputer, dispositivi incorporati e reti di dispositivi incorporati, nessuno dei quali è presente sulla mia scrivania). Questo mi rende un po 'troppo diffidente nei confronti di ganci eccessivamente aggressivi in un sistema CM.
Anche se non lavori in ambienti così esoterici, avere un hook di commit che attiva automaticamente i test per ogni singolo commit (e quindi rifiuta il commit in caso di errore) è solo una cattiva idea. È meglio incoraggiare le persone a impegnarsi frequentemente e fondersi frequentemente. L'unione di un ramo che contiene codice non vincolato è una ricetta per una buona dose di angst di gestione della configurazione. Non riuscire ad unire frequentemente è una ricetta per ancora più angoscia di gestione della configurazione.
L'estremo opposto, non avere ganci e quindi fare in modo che gli sviluppatori facciano cose imbarazzanti quando rompono la build, è anche una cattiva idea. Quello che serve è un compromesso che consenta alle persone di essere le più efficienti e allo stesso tempo di proteggere contro le persone che fanno le cose stupide che anche le persone molto intelligenti sono solite fare.