Quale approccio è migliore quando si lavora con un software di controllo del codice sorgente come TFS o VSS? Ho sperimentato approcci diversi e non so dire quale sia il migliore. Dovremmo lasciare che gli sviluppatori decidano su di esso? O una squadra dovrebbe avere una strategia unica per le operazioni di check-in di check-out?
Impegnati presto, esegui spesso commit in modo da non perdere dati.
Filiale in anticipo, spesso filiale (per le funzionalità), unisci spesso in modo da non infastidire i tuoi colleghi con un sacco di piccoli commit ai loro rami quando non li vogliono.
Non spezzare la build - essendo il ramo "stabile" del tuo attuale progetto di sviluppo da cui sono realizzate versioni interne e / o "integrazione continua".
Utilizza un VCS distribuito come Mercurial o Git in modo da poter usufruire delle funzionalità di un repository locale sul tuo PC. Non dimenticare di avere back-up di questo, sia creando fisicamente dei backup del tuo repository locale, sia disponendo di un repository gestito centralmente e back-upped al quale puoi impegnare le tue modifiche locali, nel tuo ramo, con il tuo strategia.
Dipende dalla tua strategia di ramificazione generale.
Quando esegui il branching o gli sviluppatori hanno filiali private, allora dovrebbero essere incoraggiati a fare il check-in frequentemente. Non importa, dato che il loro ramo viene unito al ramo principale solo quando è stabile.
Quando altri sviluppatori stanno lavorando sullo stesso ramo, lo sviluppatore non dovrebbe controllare nulla che rompa le cose per gli altri, quindi i commit più grandi sono probabilmente preferibili a quelli piccoli e potenzialmente pericolosi in tali scenari.
In generale, uno sviluppatore non dovrebbe eseguire il codice di check-in che interrompe la compilazione e personalmente direi che è possibile effettuare il check-in del codice ogni volta che il set corrente di unit test è soddisfatto.
Archivia in blocchi logici. Aiuta a rivedere il codice quando visualizzi le annotazioni di commit.
È più facile leggere: "Commit A: aggiunta classe X", "Commit B: Risolto bug Y", che visualizzare: "Conferma A: 10 correzioni di bug, 5 nuove classi, poche funzioni sperimentali e ultimo, ma non meno importante, la formattazione del codice sorgente cambia: evilgrin: ", o" Commit A: Funzionalità sperimentali, checkin per evitare la perdita di dati, lo eliminerò più tardi, lo prometto ".
Il check-in anticipato è non per prevenire la perdita di dati. Si tratta di integrare presto. Più a lungo stai aspettando con il tuo codice, più a lungo qualcun altro potrebbe lavorare sul codice legacy - qualcosa con cui hai fatto qualcosa ma che non hai condiviso.
Effettua il check-in abbastanza frequentemente in modo da non perdere troppo lavoro quando la tua macchina si rompe, e che unire le tue modifiche non diventa troppo difficile quando effettui il check-in.
Controlla in modo non frequente che i tuoi singoli commit comprendano una quantità tangibile di progresso e, naturalmente, lascia il repository in uno stato consistente - compilabile per lo meno, passando idealmente tutti i test unitari.
Non è necessario completare una funzionalità prima del check-in. Anche se non lo si può richiedere un "imbroglio" con i test unitari, è meglio che non effettuare il check-in per una settimana o più, rischiando di perdere tutto quel lavoro e infine affrontare un'unione impossibile.
Dipende dal tuo VCS e dalle sue capacità, in particolare si fondono. Come indicato da @MadKeithV, se usi GIT o Mecurial, usando cloni locali, commetti in anticipo e spesso. Se utilizzi dinasour come CVS e SVN come repo principale, allora meno spesso può essere un vantaggio e prendere in considerazione le sostituzioni.
Ci sono buone ragioni per usare GIT localmente e consegnare fino a un repository centrale (può essere GIT / CVS / SVN o quasi tutto ciò che vuoi) in tempi appropriati. Ancora meglio, alcuni sviluppatori possono adottare questa pratica e non dover forzarla su quelli che non la vogliono.
Gli sviluppatori dovrebbero avere voce in capitolo e lo schema deve essere flessibile. Abbiamo una regola, nessun codice rotto. Il codice incompleto è OK, ma deve "fallire" in modo ovvio (cioè il test dell'unità non sta passando) e chiaramente essere incompleto - i commit a metà forno sono pericolosi.
Deve funzionare per la squadra, e ogni squadra è diversa.
Leggi altre domande sui tag version-control