Come eseguire il refactoring in corso?

Il comando git merge --squash consente di creare un singolo commit sulla parte superiore del 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 è commit:

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

Il comando git rebase -i può anche schiacciare commit 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 fai i refactoring più del modo in cui usi Git (anche se penso che Git possa aiutarti).

Martin Fowler definisce il refactoring come :

a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

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

Potresti argomentare che questo non è pratico e che non funziona per qualcosa di grande scala. È qui che può aiutare il metodo Mikado . Si scompone un grande refactoring in una serie di piccoli refactoring creando un grafico di dipendenza. Il metodo è ricorsivo, prova a fare il tuo cambiamento, non si rompe nulla, controlla il resto, altrimenti ripristina le modifiche e prendi nota dei prerequisiti. Uno per uno, fissi quei refactoring prerequisiti fino a quando non riesci a raggiungere il tuo obiettivo principale di refactoring.

Git può davvero aiutare questo metodo. Puoi mantenere il tuo ramo (rotto) locale. Mentre commetti (e spingi) gli obiettivi secondari puoi rebase il tuo ramo obiettivo principale in cima ai commit che hai appena fatto, fino a quando non sarà più rotto.

Controlla la pagina di manuale per git rebase , in particolare la variante git rebase -i . Ti permette di riordinare, eliminare o accoppiare qualsiasi numero di commit nella tua cronologia, che suona come quello che stai cercando. Lo uso sempre nella stessa situazione che descrivi: fare molti piccoli commit che non sono adatti al consumo pubblico, quindi schiacciarli insieme in un unico commit "refactoring" prima di passare al repository condiviso.

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

IMHO, e lavorando con Git, è perfettamente buono per impegnare il tuo lavoro, anche se non viene compilato ... perché, dopo tutto, una volta che hai commesso le tue modifiche, nessuno avrà il codice disponibile (fino a quando non spingi esso). Ovviamente, prima di spingerlo, devi assicurarti che funzioni bene e compili, in modo che altri possano recuperare e unire le tue 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 completato il refactoring, esegui il checkout del ramo principale, unisci le modifiche e spinga il ramo principale.

Modifica

In questo caso puoi utilizzare git cherry-pick o giocare con git rebase