Quali sono le buone strategie di check-in per il controllo del codice sorgente per attività di grandi dimensioni?

Io uso git, quindi la mia risposta è "branch". Ramo e commetti un pasto pezzo mentre completi i vari bit.

Spingi le tue comunicazioni a monte quando sei felice, in modo che i tuoi colleghi possano rivedere le modifiche senza interrompere il trunk.

Quando tutti sono contenti del codice, si fondono e il gioco è fatto!

(Quello che tendo a fare per i rami a esecuzione relativamente lunga è periodicamente unire il tronco (master, nella terminologia git) nel mio ramo, quindi i due rami non divergono troppo radicalmente.)

Penso che la risposta cambierà in base al tipo di sistema di controllo delle versioni che si sta utilizzando: centralizzato (ad es. sovversione) o distribuito (ad es. git). Non ho alcuna esperienza del mondo reale con l'utilizzo di un sistema di controllo del codice sorgente distribuito, quindi la mia risposta si basa su ciò che facciamo con la sovversione.

Se ci sono grandi cambiamenti in corso che interromperanno il nostro bagagliaio in un periodo di tempo, o che interromperanno il resto del team in qualche altro modo, allora creeremo un ramo. Direi comunque che dovresti fare tutto il possibile per evitare di doverlo fare - la maggior parte dei cambiamenti può essere affiancata al resto del codice con poco sforzo. Ad esempio, è possibile attivare i percorsi di codice nel nuovo codice (con istruzioni if semplici o è possibile iniettare le nuove versioni in base alle impostazioni di configurazione se si utilizza un framework DI). Poi, quando hai finito, basta cambiare la configurazione alla nuova versione, testare tutto, eliminare il codice inutilizzato, testare di nuovo e infine eliminare le impostazioni di configurazione. Non puoi sempre farlo, ma a causa del sovraccarico del mantenimento di un ramo, penso che dovresti sempre verificare se è possibile.

Se fai il ramo penso che l'errore che vedo spesso fare alle persone non sia mantenere il loro ramo aggiornato con il tronco. Dovresti fondere costantemente le modifiche dal tronco al tuo ramo mentre esiste, in modo che quando hai finito l'unione inversa di tutto il resto è abbastanza banale.

In out team usiamo subversion e normalmente eseguiamo piccole modifiche direttamente nel trunk. Per attività più grandi, lo sviluppatore che lavora su di esso crea in genere un ramo privato, che viene unito al tronco una volta eseguito. Quindi il ramo privato viene cancellato. Naturalmente, mentre il ramo privato esiste, il suo proprietario dovrebbe controllarlo spesso.

Cerchiamo di evitare di avere filiali di lunga durata e fusioni da una linea all'altra, perché ciò richiede un'accurata contabilità. Al contrario, abbiamo rami relativamente di breve durata che vengono uniti al tronco una volta sola e che vengono eliminati subito dopo.

E abbiamo una regola che nulla può essere impegnato o unito al tronco finché almeno un'altra persona non guarda attraverso le modifiche e le approva.

Proprio come il solito commento delle persone del server SQL "dipende"

Se puoi, ti suggerirei di creare un ramo sul codice in modo da poter continuare ad applicare piccoli check-in del tuo lavoro. Una volta completato, eseguire un'unione di ritorno nel trunk principale.

Sì, c'è qualche possibilità di duplicare lo sforzo di reowrk in questo modo. ma almeno farai una scia di lavoro che puoi rullare, si rivelerà un vicolo cieco.