Cosa devo fare quando ho già aspettato troppo a lungo tra un commit e l'altro?

Per rispondere, devi chiederti come ti aspetti di utilizzare i risultati di questi commit in futuro. I motivi più comuni sono:

• Per vedere quale release è stato introdotto un bug.
• Per capire perché è presente una determinata riga di codice.
• Per unire in un altro ramo.
• Per poter esaminare una versione precedente per la risoluzione dei problemi relativi a un cliente o tester in quella versione.
• Per poter includere o escludere determinate parti da un rilascio.

I primi due motivi possono essere serviti altrettanto bene con un grande check-in, assumendo che sia possibile creare un messaggio di check-in che si applica ugualmente bene a ciascuna riga di codice modificato. Se sei l'unico programmatore, i commit più piccoli non renderanno più facile l'unione. Se non pianifichi di fare una versione o test con solo una parte delle tue modifiche non inviate, le ultime due ragioni non si applicano.

Ci sono altri motivi per commettere piccoli commit, ma sono fatti mentre sei nel bel mezzo dei cambiamenti, e quel tempo è passato. Queste ragioni rendono più semplice l'eliminazione di un errore o un cambiamento sperimentale e rendono più facile mantenere la sincronizzazione con i colleghi senza enormi fusioni spaventose.

Dalla mia comprensione della tua situazione come l'hai descritta, sembra che non ci sia molto o nessun vantaggio nel dividere il commit a questo punto.

Penso che qualunque cosa tu faccia, cerca di evitare di controllare il codice che sai non compilerà.

Se ritieni che la tua terza opzione sia fattibile, potrebbe essere un buon modo per farlo, purché tu possa garantire che la sequenza di commit non creerà un sistema noncompilabile. Altrimenti, fai solo un grande commit. È brutto, ma è semplice, veloce e lo fa. Andando avanti, commit più spesso .

La ragione più importante per fare commit frequenti, piccoli e significativi è aiutare la comprensione della storia del codice. In particolare, è molto difficile capire come il codice sia cambiato se è difficile generare differenze comprensibili.

L'opzione 1 offusca la cronologia delle modifiche apportate, ma altrimenti non causerà alcun problema.

L'opzione 2 offusca la cronologia delle modifiche apportate, forse un po 'meno dell'opzione 1, ma potrebbe causare altri problemi a te stesso o ad altri se presumono o comunque concludono che i commit sono distinti , per esempio può essere unito in altri rami in modo indipendente. A meno che non ci sia un strong motivo pratico per cui questo è preferito rispetto all'opzione 1, questo è meno ideale di quello.

L'opzione 3 è la migliore, a parità di tutti gli altri, ma se, come hai descritto altrove, fare ciò richiederebbe "estreme" quantità di tempo o incorrere in altri costi significativi, devono soppesare tali costi rispetto ai benefici attesi dalla creazione di un impegno più pulito.

In base alle informazioni che hai fornito, opterei per l'opzione 1. Forse dovresti impostare dei promemoria che ti richiedano di confermare le modifiche?

Prototipazione e riscrittura

Un'altra considerazione da tenere a mente, specialmente alla luce della tua nota sull'essere l'unico programmatore, e il mio sospetto che tu stia lavorando su una base di codice relativamente nuova, è che probabilmente è buono sviluppare abitudini diverse rispetto a commettere modifiche per quando si sta prototipando un nuovo codice contro il mantenimento o l'estensione del codice esistente. Probabilmente non c'è una divisione terribilmente strong tra i due, ma penso che sia ancora una distinzione utile.

Durante la prototipazione del nuovo codice, esegui il commit ogni volta che desideri salvare le modifiche, quasi certamente in un ramo, ma forse in un progetto separato. O forse anche solo lavorare al di fuori del controllo della versione. Puoi invece concentrarti sulla raccolta di prove sulla fattibilità di varie ipotesi o progetti che stai considerando. Spesso scrivo piccoli prototipi utilizzando diversi strumenti, ad es. LINQPad anziché Visual Studio per il codice C #.

Quando hai convalidato una particolare ipotesi o progetto, riscrivilo nel tuo progetto principale, idealmente in una succursale, e realizza i piccoli e significativi commit che aiuteranno meglio la comprensione degli altri (incluso il futuro) della natura delle modifiche che stai apportando.

Sebbene l'unica risposta ragionevole sia quella di non interrompere mai il trunk , alcune volte non è possibile. Ad esempio, svn può interrompere il commit se si commette troppo (forse un'opzione, o una caratteristica, non sono sicuro). In questi casi speciali, basta fare il check-in a pezzi. Dato che sei un solo programmatore, non disturberà nessuno.

Pertanto, opterei per l'opzione 1. Se non è possibile, quindi l'opzione 2.

L'opzione 3 richiede molto impegno, e semplicemente non ne vale la pena.

Try to break it into smaller commits that likely won't compile, as files have multiple fixes, changes, additional method names, etc.

Quando mi sono trovato in una situazione simile ho usato la seguente tecnica:

1. Aggiungi solo il codice che è rilevante per una particolare caratteristica: git add --patch
2. Conserva tutte le altre modifiche: git stash save --keep-index
3. Esegui test / prova la compilazione
4. Configura le modifiche se tutto è a posto, se non vai a 1

Non ho familiarità con SVN, quindi non so se questo è applicabile alla tua situazione specifica, ma la base dovrebbe essere la stessa: isolare piccole parti di codice e testarle singolarmente.

Cosa ne pensate dell'opzione 4: Eseguire il backup dello stato corrente del repository in un luogo temporaneo, ripristinare il repository al suo stato originale, creare un elenco di tutte le modifiche apportate (è comunque possibile esaminare il backup temporaneo), quindi reimplementare manualmente (e compila e prova!) come commit separati.

Questo dovrebbe essere più semplice, perché hai già scritto il codice, è solo un po 'di capire quali parti copiare e incollare dal tuo backup temporaneo.

Quando hai reinstallato ogni modifica in modo pulito, assicurando così che i commit siano autonomi, di piccole dimensioni e di compilazione, puoi eliminare il backup temporaneo e tutto sarà quasi esattamente come (tranne per l'ora / la data di commette) lo sarebbe stato se l'avessi fatto fin dall'inizio.

Sei l'unico programmatore; fai semplicemente un singolo controllo dettagliato dei pezzi importanti di ciò che hai fatto.

È probabile che ripristini "parti" di ciò che hai fatto? In caso contrario, procedi assolutamente con l'opzione 1.

Ci sono un paio di motivi per controllare il codice in un sistema di controllo della versione. E TUTTI, quando sei l'unico sviluppatore, ruotano intorno alla sicurezza, cioè se fai fallire, la macchina muore o qualsiasi altra cosa, puoi sempre tornare a quell'ultimo checkpoint.

È improbabile che un programmatore che entra nel progetto in seguito desideri eseguire il rollback a una versione che non viene compilata. Quindi, IMHO, l'opzione 2 è lunatica.

L'opzione 3 suona come una perdita di tempo, che se fossi il tuo capo e ti vedessi sprecare ore a fare questo, vorrei parlarti un po 'di quello che vale il tuo tempo.

Per iterare: controllando il tuo codice stai coprendo / salvando il tuo culo in caso di guasto sulla tua macchina. Tutto il resto, in una squadra di un solo uomo, è la vetrinistica.

La mia regola è: nessun check-in senza una seria revisione del codice. Se sono da solo, dovrò rivedere il codice da solo, ma sarà esaminato. Sembra che tu abbia una quantità di modifiche al codice che qualcun altro non è in grado di esaminare, quindi non puoi rivederlo da solo (la revisione del tuo codice è più difficile e richiede più disciplina, perché fai automaticamente l'ipotesi sbagliata che il tuo codice sia corretto ).

La regola totalmente inderogabile di tutti è la seguente: mai verificare il codice che non è nemmeno compilato, e seriamente evitare il check-in del codice che non funziona.

Soluzione: copia il tuo codice modificato, torna al punto originale. Unisci un cambiamento alla volta nel codice originale, esaminalo, testalo, verificalo. Con il metodo di programmazione che hai descritto, sei destinato a trovare alcuni bug gravi in questo modo.

È anche un buon modo per allenarti con buone abitudini di programmazione.

Penso che tu ti stia preoccupando troppo. Se sei l'unico programmatore e non hai una scheda tecnica a cui lavorare contro, dipende interamente da te ciò che fai. Presumo che nessuno vi punisca per aver eseguito un commit di grandi dimensioni, quindi gli unici problemi che si incontreranno sono tecnologici, come non essere in grado di ripristinare singole modifiche ai file all'interno del commit. Dal momento che hai solo il controllo del repository in questo momento, comunque non dovresti preoccuparti.

C'è una linea da tracciare tra pragmatismo e dogmatismo. Quello che hai fatto non sarebbe una buona idea in una squadra e probabilmente non dovrebbe essere ripetuto in futuro, ma nella tua situazione mi limiterò a inviare il grosso commit.

Il problema non è dovuto a lunghi ritardi tra i commit ma al fatto che si mantiene il codice in uno stato non compilabile per troppo tempo. Prima di tutto qual'è la tua definizione di "lunga"? Per alcune persone 5 minuti per lo stato di transizione è troppo, ma alcuni possono lucidare il loro codice per giorni senza nemmeno provare a eseguire il compilatore.

In effetti non importa - ciò che importa è che hai perso il controllo del tuo codice, il tuo codice è diventato ingestibile. Questo è normale, significa solo che hai un debito tecnologico ed è ora di pensare al refactoring. Quindi sei frustrato? Il codice non si compila, non hai nemmeno test unitari? Come puoi pensare al refactoring in questo caso? Nessun problema. Termina la tua "codifica da cowboy" e inizia a pulirlo. Idealmente prova a scrivere alcuni test. Non hai tempo per questo? Ok, inizia da piccoli miglioramenti.

Alcune modifiche non richiedono test. Cambia il nome della variabile per più adatto, sposta il codice ripetuto in una funzione separata, ecc ... Avrai un'idea migliore del tuo codice. Dopo di che puoi fare cambiamenti più grandi. Di nuovo, prova a scrivere test se possibile. Rendi il tuo codice gestibile.

Dopo vedrai che il prossimo cambiamento non ti porterà "troppo a lungo" (qualunque cosa significhi).