Quando le modifiche al codice dovrebbero essere controllate nel controllo del codice sorgente?

One is to check in the code as soon as the change is complete, so that your co-workers can see the change and to minimize any merging that has to be done when putting a build together.

The other is to not check in any code until you are certain that you are ready for a build, so that if a problem is found, you can address the issue as quickly as possible.

Questi sono veramente entrambi corretti. Dovresti effettuare il check-in non appena avrai terminato il codice. Il tuo check-in dovrebbe sempre essere compilato.

Questo è l'intero punto dell'integrazione continua e cose come i check-in con gating. Hai una fase di compilazione per assicurarti di non aver infranto la build. Hai una suite di test unitari per assicurarti che il codice non si rompa. Potresti avere una serie di test sul fumo per assicurarti che il codice funzioni su un ambiente reale. Tutto ciò fornisce un'abbondante fiducia in # 2, quindi puoi rispettare # 1.

Vengo dal lato che crede che i commit dovrebbero essere frequenti. Esattamente quanto frequente dipenderà dal tuo stile di sviluppo personale. Alcuni nel mondo TDD si impegneranno ogni pochi minuti (ogni ciclo completato), altri forse un paio di volte al giorno in quello che sentono essere un buon punto. Alcuni vantaggi dei commit frequenti sono:

• Viene eseguito il backup del lavoro, utile non solo in caso di errore del disco o di qualche altro problema di sistema, ma di problemi umani come lasciare il laptop a casa (nel senso che puoi saltare su un sistema di riserva di riserva se disponibile) e riprendere dove hai interrotto o malattia (qualcun altro può riprendere il tuo lavoro)
• In relazione a ciò, la possibilità di eseguire il rollback se ti accorgi di aver intrapreso il percorso sbagliato a un certo punto, senza dover necessariamente buttare via tutto ciò che hai eliminato
• I commenti significativi con il commit forniranno una storia di sviluppo, aiutando te e gli altri membri del team a comprendere il cambiamento
• Riduzione della probabilità di conflitti di fusione, come risultato dell'utilizzo di piccoli commit incrementali. Laddove si verificano conflitti, sono più facili da risolvere
• In un ambiente CI, riceverai una notifica prima di qualsiasi errore di compilazione o se hai interrotto qualsiasi test e puoi correggerli mentre il lavoro è ancora fresco e prima che causino problemi agli altri membri del team

Invece di diramazioni puoi usare i pulsanti di selezione delle funzioni. Questi possono essere usati per mantenere la tua funzione nascosta su percorsi di codice separati fino a quando non è pronta per essere rivelata. Tuttavia questo introduce complessità e sovraccarico, quindi in genere non vale la pena farlo per piccole attività.

Non sono chiaro cosa intendi con "se viene trovato un problema, puoi risolvere il problema il più rapidamente possibile". I commit sono rapidi ed economici, correggi il bug e ne fai un altro (commit, non bug). Se d'altra parte intendi "oh no, ho trovato un problema importante con la mia funzione e voglio estrarre l'intera cosa dalla build", la funzionalità di commutazione può anche essere d'aiuto in questo senso, semplicemente spegnendola.

La domanda "possibili duplicati" si concentra sulla possibilità di perdere il lavoro in caso di calamità. Direi che il controllo della versione non dovrebbe essere usato come strumento di backup. Dovrebbe riflettere le fasi di sviluppo di un sistema, si dovrebbe evitare il rumore che sono in realtà solo i momenti di Ctrl + S e non significano nulla nella progressione dello sviluppo. Almeno nel bagagliaio o in qualsiasi ramo. Quella cosa di shelving può essere buona per i salvataggi intermedi però.

La gente dell'altro thread sembra amare la ramificazione. Io non. Dovresti evitare di diramarti se puoi. A volte non c'è modo di aggirarlo ma è un potenziale dolore che aspetta di accadere, una volta che hai dovuto fonderti potresti scoprire che non è così facile più così è sempre un potenziale rischio.

La fonte principale di linee guida in questa materia sarebbe la tua azienda e il punto del tuo ciclo di sviluppo. Se sai che non consegnerai nulla per un mese, ti comporterai in modo diverso da quando devi consegnare domani. Qualunque cosa tu controlli devi essere stabile o può essere una versione di prova interna? Dipende dalle circostanze, entrambi possono essere validi in momenti diversi.

Non esiste una soluzione perfetta a questo problema

Per eseguire il test completo di una funzione è necessario installarlo in un ambiente di prova.

Ma per implementare il codice, anche per testare l'ambiente normalmente richiederà il check in e il versionamento!

Ovviamente se esegui il check-in e la versione del codice non funzionante hai una versione del tuo software che non vuoi mai rilasciare e dovrai eseguire un altro checkin per risolvere il problema! quindi è "una brutta cosa" (tm)

Tuttavia, sicuramente tutti accettano che anche il controllo più attento non catturerà tutti i bug? Pertanto, è necessario accettare che qualsiasi versione del software sia potenzialmente difettosa e consentire correzioni di bug nelle proprie versioni e splicing di implementazione