Dividere il progresso della codifica in commit significativi senza troppi sovraccarichi

Penso che devi essere molto pragmatico durante la programmazione. Anche se potrebbe essere possibile formulare lo schema, il flusso di lavoro o l'implementazione perfetti, a volte è sufficiente portare a termine il lavoro. Ecco cosa faccio:

Uso la capacità di git di mettere in scena / commettere singoli hunk e linee, quando possibile, per separare i cambiamenti non correlati, anche se, occasionalmente, questo può introdurre problemi temporanei, se la separazione non è stata eseguita correttamente. Poiché le modifiche saranno adiacenti, di solito non è un problema enorme, a meno che non si disponga di una politica di test di ogni singola modifica nella pipeline CI.

Quando il cambiamento non correlato è troppo grande, lo inserirò in un elenco di cose da fare, e di solito lo riprenderò subito dopo, mentre è ancora fresco nella mia mente. A volte potrebbe volerci un giorno o due prima di poter tornare ad esso, dipende dal mio attuale compito e dalla mia linea di pensiero. Occasionalmente inserirò semplicemente un TODO: accanto al codice offensivo, se non ho una buona soluzione pronta.

Succede che non è pratico separare le cose e io eseguirò il piccolo aggiustamento insieme al lavoro originale.

La dimensione del cambiamento è solitamente il fattore determinante quando scelgo la rotta da percorrere, ma alla fine preferirei ignorare una regola del flusso di lavoro piuttosto che lasciare un odore.

Il mio editor ha un plug-in che rende estremamente facile mettere in scena singole parti di un file. Immagino che altri editor di programmatori potrebbero avere plugin simili, anche se puoi sempre farlo in modo manuale con git add --patch | -p . Quindi uso git stash per salvare le altre mie modifiche per testare il mio piccolo commit in isolamento. Quindi, dopo aver eseguito il commit, eseguo solo un git stash pop e riprendo da dove ho interrotto. Questo è esattamente ciò per cui sono state progettate queste funzionalità.

Il trucco non è quello di apportare modifiche a meno che tu non sia disposto a impegnarti tanto quanto il cambiamento merita.

Quello che tendo a fare è aggiungere una lista di cose da fare (a volte aggiungendo commenti al codice, a volte in una nota su un bug ticket, e talvolta aggiornando il codice in un ramo separato sapendo che la correzione verrà unita in infine). Se non ci sono ticket di bug per un rollup di problemi di qualità minori, ne alzo uno specificamente per questo, così io e tutti gli altri possiamo dire quale sia stata la ragione di tali modifiche al codice quando il ramo viene unito. Non faccio mai solo modifiche per il gusto di farlo, tutto diventa tracciabile, così i miei colleghi non saranno troppo sorpresi quando il codice cambia.

Quindi in breve - sì, ignorali quando codifichi. Se stai aggiungendo una funzione, non essere tentato di aggiungere 2 funzionalità, non importa quanto piccole. Se qualcuno decide di annullare il tuo ramo (perché la tua funzione non è più necessaria, ad esempio), perderai anche tutti i tuoi mini-bugfix. Allo stesso modo, non vuoi fare una piccola "correzione" in qualche codice critico che funzionava correttamente.

Un'opzione che uso un bel po 'è quella di aggiungere commenti di TODO , quindi fare molti commit "parziali" frequenti, usando git add --patch per selezionare le parti rilevanti del file. Quindi usa git rebase --interactive per riordinare e unire i commit parziali nella feature finale e il fixup si impegna prima di spingerli.

Ciò mantiene pulito il tuo commit principale e ti consente comunque di risolvere altri problemi che trovi immediatamente.

Non c'è niente di sbagliato in git rebase in questo contesto, poiché stai solo riscrivendo i commit locali.

Un'altra opzione potrebbe essere quella di "git stash" le tue attuali modifiche. Il flusso di lavoro sarà simile a questo:

1. Iniziare a fare modifiche relative a Caratteristica A
2. Scopri Bug B e decidi di risolverlo immediatamente
3. Dalla riga di comando del repository esegui git stash (Dopo di che il tuo codice tornerà allo stato in cui si trovava prima di iniziare a lavorare su Caratteristica A )
4. A questo punto le modifiche non salvate per Caratteristica A sono memorizzate nello "stash"
5. Apporta le modifiche al codice necessarie per correggere Bug B e ripristinare il commit nel repository
6. Dalla riga di comando lancia git stash pop
7. Le modifiche non vincolate per Caratteristica A sono ora estratte dalla memoria e ripristinate sul codice in corso accanto alla correzione (già impegnata) per Bug B

Separa fase (e commit) le modifiche relative alla correzione di bug. In Git Extensions, questo è estremamente facile da fare. Dalla riga di comando, penso che devi fare git add -p .