Risolvere un bug mentre si lavora su una parte diversa del code base

Ho fatto 1 e 2 e alla fine, penso di preferire # 2. Permette una maggiore visibilità per la correzione dei bug, che potrebbe essere importante per QA / note di rilascio / altri sviluppatori.

Ho anche trovato una situazione in cui quello che pensavo fosse un bug in realtà non lo era (non dicendo che questo è il caso qui), e "fissarlo" in un commit separato ha permesso a un altro dev di contattarmi e spiegare cosa era cosa invece della "correzione" mi sono perso nel mio normale check-in.

In genere vado per il n. 2. Rende il repository più pulito e rende i registri più comprensibili. Lo odio quando altri sviluppatori con cui lavoro eseguono 15 correzioni di bug, funzionalità e refactoring diversi nello stesso commit.

Inoltre, a seconda di come il tuo team esegue il monitoraggio dei difetti, potresti dover cercare nel repository dei difetti per assicurarti che se il difetto che stai correggendo è lì, contrassegni l'elemento completo. In alternativa, potrebbe essere necessario creare un nuovo elemento e contrassegnarlo come completato in modo che il sistema di difetti e il codice repo corrispondano.

I do # 2. L'uso di strumenti come git rende banale la suddivisione in più commit. Se non riesci a convincere la tua squadra a passare a strumenti più moderni, git-svn ti darà una parte decente di ciò che useresti per risolvere questo problema. Questo post sul blog offre una buona panoramica del flusso di lavoro che stai cercando di risolvere: The Thing About Git

Scelgo l'opzione non scritta (4): Dividi il tuo progetto in assiemi / librerie altamente specializzati, in modo che i bug non correlati si trovino sempre in una posizione diversa nella struttura di controllo della versione.

Chiedo scusa se suona molto male, ma intendo sinceramente. Rabbrividisco ogni volta che vedo un progetto monolitico con cento forme e spazi dei nomi che non hanno niente a che fare l'uno con l'altro. Ero solito affrontare lo stesso dilemma spesso, chiedendomi se e come dovevo suddividere i commit che si occupavano di diverse aree funzionali; solo molto più tardi mi sono reso conto che avere tutte queste diverse aree funzionali in un singolo progetto committente era, di per sé, un grande difetto di progettazione.

Ancora spesso trovo bug totalmente non correlati mentre sto lavorando su una funzione specifica. Potrei lavorare sull'interfaccia utente e trovare un bug in alcune logiche di business, e devo sistemarlo prima che possa andare avanti. La differenza è che la logica aziendale è sempre in un assembly / progetto diverso dall'interfaccia utente, quindi tutto ciò che devo fare è apportare una modifica molto piccola al BL e procedere con un commit molto minore, quindi continua a lavorare.

Avere un'organizzazione del progetto davvero buona rende non solo possibile, ma abbastanza facile da gestire questi problemi senza seppellire un cambiamento, rompere la build, o impantanarsi in un ramo / fusione irritante (anche se stai usando un DVCS è non totalmente indolore)

Se ti manca questa opzione, cioè sei un dev junior senza voce in capitolo nell'organizzazione del progetto, allora andrei semplicemente con il n. 1 e prenderemo le note appropriate nel log in modo che altre persone sappiano perché hai fatto quello che hai fatto. Se hai apportato una modifica importante , pubblica anche una segnalazione di bug nel tuo sistema di tracciamento dei problemi per dare visibilità a ciò che hai risolto e perché.

Cerco di fare # 2. Se è davvero un problema separato, è probabile che sia in un file diverso da quello su cui stai lavorando. Dovresti essere in grado di controllare il file come un commit separato, anche se è fatto nello stesso repository su cui stai lavorando. Per tutti i motivi già indicati, ha senso avere commetti quanto più indipendenti possibile, per tracciare e, se necessario, annullare il cambiamento.

Di solito aggiusto il bug, e poi continuo a cosa stavo lavorando. Quando è il momento di impegnarsi, supponendo che la correzione sia in un file separato, eseguo due commit simultanei - il primo è un commit parziale che contiene solo la correzione di bug, e il secondo è tutto il resto.

Risposta breve: # 2. Vuoi davvero che il bugfix (con la sua nota nel tracker!) Tagga nella tua cronologia delle versioni come entità separata.

Risposta più lunga:

• inciampare nel bug
• Scrivi un test o più dimostrando il bug
• Esegui il test di prova
• Confida solo quel cambiamento e i suoi test ( git add --interactive o darcs record -i o comunque il tuo VCS lo fa) (*)
• Torna a quello che stavo facendo.

(*) In CVS (no, davvero) a volte ho un albero pulito estratto e una copia su cui lavoro. Quindi uso un merger - winmerge, nel mio caso - per estrarre solo il bugfix nell'albero pulito in modo da poterlo commit separatamente. (L'altra opzione è quella di rinominare i file modificati, cvs update e unire. Una volta confermata la modifica, rimuovere il file e rinominare i file spostati nei loro nomi originali.)

Qualcosa da notare è che di solito trovo bug relativi a ciò a cui sto lavorando, o che sono in stretta prossimità lessicale. Sarei sorpreso se fosse normale per le persone trovare bug in parti non correlate della base di codice - perché stai leggendo codice non correlato quando correggi il bug? (Sì, questo è esattamente l'opposto di quello che dice Aaronne!)

Risolve il bug e faccio commit separati , uno per ogni correzione / funzionalità.

La maggior parte delle volte le modifiche non sono nello stesso file, quindi è facile separare i commit. Se le modifiche sono nello stesso file, uso TortoiseHg (un front-end GUI mecurial) per selezionare con precisione i diff che voglio commettere (penso che sia possibile farlo sulla riga di comando con l'estensione Record , ma è meno conveniente)

Alcune persone usano le Code Mercurial per isolare le correzioni minori mentre si lavora su una funzione. Le correzioni minori sono impilate nel MQ e quando la funzione è finita e impegnata, viene anche eseguito il commit del contenuto della coda (un changeset per ogni voce nella coda).

Di solito faccio # 2. Salvare il mio lavoro corrente altrove: questo di solito funziona bene creando una patch. Anche alcuni IDE (IntelliJ) consentono modifiche alle scaffalature che sono esattamente questo: salva il lavoro corrente altrove.

Ciò che faccio dipende dal fatto che il bug si trovi davvero in una parte diversa. Se lo è, quindi il check-in è indipendente dalle mie modifiche a metà. Faccio il resto, costruisco quella parte diversa per essere sicuro di non aver fatto qualche errore banale, di testarlo (forse facendo quello che mi impediva di fare) e di controllarlo per spiegare cosa stava succedendo. Spesso farò un oggetto di lavoro per esso, e dopo il check-in / risolvere, assegnare la WI a un tester. Poi torno a quello che stavo facendo.

Se è tutto impastato con i file che ho cambiato a metà, non posso costruire e testare quella parte in modo indipendente. In tal caso, faccio un altro WI per esso e quando effettuo il check-in delle mie modifiche risolvo entrambe le WI con lo stesso checkin, che di solito è contro i miei principi, ma si applica bene in questo caso.

In entrambe le circostanze il bugfix finisce per essere testato da me, archiviato con una sorta di percorso in modo che le persone capiscano perché ho modificato questo codice quel giorno e una WI è stata assegnata a qualcun altro per confermare che ora è corretta.

Facciamo # 1. # 2 suona bene, ma non posso dire che abbiamo avuto problemi con # 1 che il # 2 avrebbe risolto.

Un fattore aggiuntivo nella mia azienda è la creazione di app Web, e il nostro test è quasi interamente attraverso l'interfaccia web - approssimativamente, ciò che le persone chiamano test funzionali piuttosto che test unitari. Tutti i test passano prima del check-in. La suddivisione dei commit in bit più piccoli significherebbe eseguire i test una volta per ogni bit, e ciò richiederebbe più tempo. Mi piacerebbe avere una suite di test molto più veloce, che ci permetterebbe di eseguire commit più piccoli, ma semplicemente non ce l'abbiamo.