Controllo della versione: gestione del codice incompleto / non funzionante

Fai un passo più in là della semplice creazione di un ramo per risolvere questo specifico problema e passa alla creazione di un ramo per ogni funzione, bugfix, ecc ... che decidi di implementare. Ci si dovrebbe aspettare che ognuno di questi rami abbia un codice in errore in qualsiasi momento. Una volta che il codice è stato completato, può essere unito / testato rispetto al ramo principale del tuo repository.

Ciò ti consentirà di risolvere il problema attuale relativo alla posizione in cui memorizzare codice incompleto e non funzionante e ad aiutarti a organizzare i tuoi pensieri e le tue idee. Se vuoi provare una nuova caratteristica pazzesca nel tuo tempo libero, devi semplicemente creare un ramo per quella funzione e iniziare a lavorarci su. Puoi rimuoverlo per due mesi in uno stato non funzionante e riprenderlo in un secondo momento unendovi nuovamente le modifiche che sono state apportate al ramo principale.

Un buon schema di una ramificazione in questo modo usando l'integrazione continua (CI) può essere trovato qui: link

Se utilizzi un DVCS, è semplice come "4. Crea un repository remoto per ogni sviluppatore."

Per la maggior parte dei CVC, devi davvero usare le filiali. TFS offre mensole che possono essere utilizzate per questo scopo.

È qui che brillano le buone strategie di ramificazione: nulla di incompleto dovrebbe entrare in master , ma ciò non significa che il codice incompleto e work in progress non possa raggiungere il repository condiviso. Ci sono molte buone ragioni per farlo, come backup / macchine per cambiare / cambiare posizione / aiuto & ripassa / dà a noi anziani una buona idea che i ragazzi stanno facendo di più che giocare a WoW.

I rami sono la tua migliore opzione. La regola d'oro è di non rompere la build. Supponendo che sia il tronco principale e si stia costruendo correttamente, quindi creare un ramo e mettere il tuo lavoro temporaneo lì va bene. Preferisco di gran lunga vedere il lavoro incompleto memorizzato nel controllo di versione di quello lasciato su un computer che viene distrutto però.

Se lavori con CVCS puoi provare a rotolare con un tronco. Ho visto questo fatto molto bene alcune volte. La cosa da fare è avere un'integrazione continua con i test unitari e test contigui su quel tronco.

Una regola: Non rompere la build e non interrompere la funzionalità.

Ma ci sono alcuni checkin 'incompleti' che sono accettabili. Ad esempio, se stai per aggiungere una funzione e hai bisogno di controllare alcune classi di modelli che non sono usate da nessuna parte, va bene, menziona solo che cosa sono nei registri di commit. Se è necessario estendere una classe esistente per avere più funzionalità, anche questo è OK.

I check-in frequenti hanno 3 vantaggi:

1) Ognuno vedrà presto la tua "direzione". Saranno in grado di coordinarti con te sul loro lavoro e utilizzare le tue modifiche se vedono il loro valore. Un problema con la ramificazione delle funzionalità è che le persone possono contemporaneamente inventare la stessa ruota.

2) Le tue cose saranno testate prima. Un problema con la ramificazione di tutto è che devono esserci 2 cicli di test: uno per la funzionalità eseguita nella filiale e uno per la funzione dopo l'unione.

3) Se le cose si rompono, saranno catturate da altri sviluppatori ancor prima che vadano al QA. I bug sono meglio affrontati il prima possibile.

Un avvertimento: questo funzionerà su team di piccole-medie dimensioni. Ad un certo punto le persone iniziano a pestarsi troppo le dita dei piedi e tu sarai costretto a diramarti.

Nell'uso normale, non commetterei modifiche al controllo del codice sorgente fino a quando una funzionalità non è completa e testata. La "brutta tempesta invernale" sembra un evento raro, che potrebbe giustificare regole speciali. Se qualcuno non si trovasse in una posizione ideale, allora chiederei loro di salvare quelle modifiche su un'altra unità, o forse di comprimerle e inviarle per e-mail al caposquadra. Se entrambi sono proibiti dal tuo ambiente di lavoro, allora interromperò l'utilizzo normale e li farei semplicemente rimettere il codice incompleto al controllo del codice sorgente. Se si rompe qualcosa, allora è piuttosto semplice il rollback. E questo dovrebbe essere un evento raro piuttosto che la norma.