non effettua il check in dalla root del progetto

Non essere disturbato dalla pratica di controllare i singoli file - se qualcuno può farlo e farlo funzionare, va bene.

Fai essere infastidito da persone che controllano build non funzionanti. La preoccupazione principale è il risultato. Affrontare la causa principale è assolutamente una buona idea, ma il miglior primo passo è trovare la motivazione appropriata per interrompere il controllo del codice non funzionante.

Se le build rotte sono un problema, ti suggerirei di evangelizzare le build automatizzate per la tua squadra. Se qualcuno controlla un file che interrompe la compilazione, una build automatizzata ti dirà immediatamente, piuttosto che aspettare che arrivi il prossimo ragazzo e scoprirlo, trascorrendo 15 minuti a rintracciare la persona che ha effettuato il check-in ha rotto la build (perché potrebbe non essere stato l'ultimo check-in!) e così via ...

Se le persone eseguono il check-in dei file uno alla volta, è possibile ritardare la creazione automatica di alcuni minuti dopo aver rilevato un check-in, per consentire alle persone di archiviare il resto dei propri file. Anche questa è causa di preoccupazione (domanda: inseriscono i commenti appropriati nel messaggio di commit?), Ma non è un grosso problema come la rottura della build.

Sì, penso che tu abbia ragione.

Nel migliore dei casi (se lo fanno sempre correttamente) quello che stanno facendo è solo un modo più lento di fare ciò che stai facendo.

Il problema più grande è che sta esponendo meno delle pratiche di lavoro ideali. In primo luogo sembra che stiano lavorando su più di una cosa alla volta - quindi piuttosto che lavorare in piccoli passi, stanno facendo dei grandi cambiamenti che sono irrilevanti e quindi devono fare qualche altra operazione nel mezzo e commetterlo. O forse non si stanno ripulendo da soli e le loro modifiche locali senza commit hanno tutti i tipi di cianfrusaglie (grandi blocchi di codice commentato, metodi ridondanti, roba rotta che era solo un esperimento temporaneo).

Ho lavorato con persone che fanno questo ed è sempre un incubo: la situazione peggiore è quando hanno una discarica non accettata localmente, quindi quando aggiornano la loro versione locale viene borked, ma alcune delle cose che vogliono mantenere sono nel stessi file della spazzatura. Di conseguenza, si perdono nel sistemare le cose che vogliono tenere da quelle che vogliono ripristinare.

Le liste dei cambiamenti sono un concetto fantastico. Solo una serie di modifiche coerenti (che risolve una cosa) dovrebbe far parte di una singola lista di modifiche che viene controllata insieme.

Per aggiungere alla mia risposta: Idealmente dovresti essere in grado di creare un elenco di modifiche dei tuoi file, passarlo a un elenco pulito (completamente sincronizzato con il repository) applicare l'elenco delle modifiche e crearlo prima del check-in. Se i tuoi compagni di squadra non si prendono la briga di farlo, fanno parte del processo di revisione del codice.

Lasciando il problema ortogonale di come non dimenticare di aggiungere i file a parte, il tuo approccio può portare ad un altro problema: verificare accidentalmente le modifiche che erano solo per test ecc.

La selezione manuale dei file di origine (o delle sottodirectory) per il commit è un approccio possibile che può essere eseguito in modo responsabile e senza interruzioni regolari delle build (utilizzando le informazioni sullo stato del VCS). Il vero problema qui è diffondere il changeset su molti diversi check-in, uno per ogni file. Ciò porterà inevitabilmente a difficoltà quando la cronologia delle versioni è necessaria per qualsiasi cosa.

È possibile lavorare un po 'sciatta se si dispone di buoni strumenti per evitare il verificarsi di cattive build. Generalmente questo manterrà la squadra più felice che richiedere una vigilanza costante.

Configurare una build continua è il primo passo. Se le build rotte sono un problema, lo rivelerà.

Quindi potresti scrivere uno script di invio che, dato un elenco di file, controlla il project head in una nuova directory, li aggiusta, esegue test e controlla i file insieme se passano. Quindi possono scegliere se preferiscono, purché utilizzino lo script di invio.