Come eseguire il refactoring in corso?

Quindi, ho questo grande progetto, che è in fase di refactoring da parte mia. Sto cambiando un sacco di cose, quindi non c'è alcuna possibilità di farlo compilare presto. Vivo in uno speciale ramo git che ho nominato cleanup(che alla masterfine si fonderà, ovviamente).

Il problema è che io / noi abbiamo la politica di non commettere mai codice non di compilazione (idealmente dovrebbe funzionare anche, ma deve compilare e collegare, per lo meno). Quindi, fino a quando non ho finito con questo enorme compito, non sono in grado di impegnare nulla (per la revisione o per la contabilità).
Non è così che mi piace lavorare (credo che la maggior parte delle persone si impegni almeno una volta al giorno).

Cosa pensi? C'è una soluzione che sto trascurando?
Posso in seguito dire a git di aggregare commit o qualcosa del genere? Potrei vivere con commit non compilante purché rimangano nel cleanupramo.

modificare

Per quanto riguarda la spinta / impegno: sono consapevole che si tratta di una differenza enorme, ma in seguito ci saranno revisioni interrotte, quando unirò le mie cose master. Quindi, se navighi nella storia (o git bisect...), le revisioni "locali" saranno accessibili in tutto il mondo. Quindi solo impegnarsi a livello locale e non spingere non è la soluzione migliore, perché in seguito ti causerà problemi (quando il soggetto è chiuso e dimenticato per un po 'di tempo).

In breve: gli commit locali verranno spinti alla fine. La cronologia globale non dovrebbe mostrare commit non compilanti.

Il git merge --squash comando consente di creare un singolo commit sopra il ramo corrente il cui effetto è lo stesso di unire un altro ramo. Il comando aggiorna l'albero di lavoro e mette in scena le modifiche all'indice, quindi tutto ciò che devi fare è eseguire il commit:

git checkout master
git merge --squash cleanup
git commit -m "Merge cleanup branch"

Il git rebase -icomando può anche eseguire operazioni di compressione ma richiede più lavoro.

Una riscrittura non è un refactoring

Mi rendo conto che sei interessato a come usare Git, ma direi che dovresti considerare di cambiare il modo in cui esegui i refactoring più del modo in cui usi Git (anche se penso che Git possa aiutarti).

Martin Fowler definisce il refactoring come :

una tecnica disciplinata per ristrutturare un corpo di codice esistente, alterando la sua struttura interna senza modificarne il comportamento esterno.

Il suo cuore è una serie di piccoli comportamenti che preservano le trasformazioni. Ogni trasformazione (chiamata "refactoring") fa poco, ma una sequenza di trasformazioni può produrre una ristrutturazione significativa. Poiché ogni refactoring è piccolo, è meno probabile che vada storto. Il sistema continua a funzionare completamente dopo ogni piccolo refactoring, riducendo le possibilità che un sistema possa rompersi seriamente durante la ristrutturazione.

Se si applica questo metodo, è possibile eseguire il commit (e il push) su base regolare.

Potresti sostenere che ciò non è pratico e che non funziona per qualcosa di grande scala. Questo è dove il metodo Mikado può aiutare. Si decompone un grande refactoring in una serie di piccoli refactoring creando un grafico delle dipendenze. Il metodo è ricorsivo, prova a apportare le modifiche, non interrompe nulla, controlla, altrimenti ripristina le modifiche e prendi nota dei prerequisiti. Uno per uno, risolvi quei refactoring pre-requisiti fino a raggiungere il tuo obiettivo di refactoring principale.

Git può davvero aiutare questo metodo. Puoi mantenere il tuo ramo locale (rotto). Mentre commetti (e spingi) i sotto-obiettivi puoi raggiungere il rebasetuo obiettivo principale in cima ai commit che hai appena fatto, fino a quando non viene più interrotto.

Controlla la pagina di manuale per git rebase, in particolare la git rebase -ivariante. Ti consente di riordinare, eliminare o comprimere qualsiasi numero di commit nella tua cronologia, il che suona come quello che stai cercando. Lo uso sempre esattamente nella situazione che descrivi: eseguendo molti piccoli commit che non sono adatti al consumo pubblico, quindi li comprendo in un unico commit di "refactoring" prima di passare al repository condiviso.

Stai usando Git, quindi impegnarti non implica necessariamente spingere tue modifiche ....

IMHO, e lavorando con Git, è perfettamente buono impegnare il tuo lavoro, anche se non si compila ... perché, dopo tutto, una volta che commetti le modifiche, nessuno avrà il codice disponibile (fino a quando non lo invii). Naturalmente, prima di inviarlo, è necessario assicurarsi che funzioni correttamente e si compili, in modo che altri possano recuperare e unire le modifiche senza problemi.

Inoltre, stai lavorando su un ramo diverso da quello principale. Quindi, se vuoi (e lo consiglio), non spingerai mai il tuo ramo. Una volta terminato il refactoring, basta verificare il ramo principale, unire le modifiche e spingere il ramo principale.

modificare

In tal caso è possibile utilizzare git cherry-picko giocare congit rebase