Quando si effettua una correzione a un commit precedente, è necessario rifare nuovamente o aggiungere un commit di correzione separato?

Uno scenario comune nello sviluppo del software è la revisione del codice di qualcun altro. Uno strumento comune per farlo è l'apertura di una richiesta pull.

La mia domanda è, quando vengono rilevati problemi nella revisione, in caso di modifiche

essere impegnato separatamente (nuovo commit)
o dovrebbe essere modificato il commit esistente (supponendo che nessuno si stia ramificando dal tuo commit precedente ... poiché riscrivere la cronologia da un branch condiviso è una cattiva notizia).

Per il primo scenario, è facile tenere traccia delle modifiche incrementali, sebbene aggiunga un po 'di rumore alla cronologia del commit. La seconda opzione ha i pro e i contro.

git code-reviews repository

— loeschg
fonte

Dici "rumore" per il commit, ma ho letto che è una storia accurata . Perché provare a mascherare ciò che è realmente accaduto nella cronologia dei commit? Una revisione del codice è una revisione del codice, non è necessario dipingerla come qualcos'altro. Il mio voto sarebbe andare al commit separato, e non il rebase in questo caso.

— Thomas Stringer,

Di solito faccio entrambe le cose. Pubblica ogni commit separatamente, quindi una volta completata la revisione rifai e unisci. GitHub continua le discussioni sulla richiesta pull anche dopo che tali commit sono stati rimossi o sostituiti, quindi non vi è alcuna sostanziale perdita di cronologia a causa del rebasing. Ottieni il meglio da entrambi i mondi.

— Ajedi32,

ho sentimenti contrastanti riguardo al fatto che ho commesso qualcosa che in qualche modo in seguito ho determinato crash del sistema. quelli che commettono, se scopro presto il loro difetto del mio fare, sono quelli che vorrei ripristinare dalla storia. ma sono solo frammenti, non costano così tanto, quindi probabilmente la cosa più sicura, economica e coerente da fare (come nella dottrina) è sempre impegnarsi separatamente e lasciare il relitto della macchina nella fossa per tutti vedi ora e per sempre. .... e puoi contrassegnare ogni ramo difettoso con un messaggio inconfondibile per non costruirci sopra, quindi nessun ramo condiviso.

— robert bristow-johnson,

Puoi spiegare cos'è il "rebasing" e quando lo vorrei?

— Kilian Foth,

Si presume che la correzione non presenti nuovi problemi e correzioni complete. Ma molte correzioni meritano una revisione per conto proprio - e questo è probabilmente molto più semplice quando le modifiche incrementali possono essere riviste separatamente.

— Doc Brown
fonte