In qualsiasi progetto in cui condividi il codice dovresti essere molto riluttante a modificare la cronologia e forzare la spinta. Questo è particolarmente vero per il codice open source.
Non ho capito bene la tua domanda, ma sembra che quando cerchi di aggiustare qualcosa finisci per rompere qualcosa, che è rivelato da una sorta di suite di test automatizzata.
Una buona pratica è aprire una richiesta pull al codice, anche se la possiedi. In questo modo, qualsiasi servizio di integrazione continua può eseguire test sul tuo codice. Inoltre, è necessario eseguire la suite di test sul proprio codice prima di eseguire il push. In questo modo sai che la correzione non ha infranto nulla.
Una correzione dovrebbe essere un commit separato in quanto non è una funzionalità. Questo perché all'avvio della versione del codice, la gente si aspetta un determinato comportamento da una determinata versione del codice. Se hai cambiato la cronologia, quelle aspettative non possono corrispondere. Inoltre, le persone che usano una particolare versione del codice potrebbero aver incontrato il bug che hai risolto. Si aspetteranno che una nuova versione del codice risolverà il problema. Se rebase e schiacci il codice, inserirai la correzione in un posto che non si aspetteranno.
Se stai scoprendo che devi implementare troppe correzioni per funzionalità, forse dovresti rallentare, scrivere test più completi e cercare di coinvolgere il tuo pubblico nelle revisioni del codice in modo da catturare i bug prima che diventino parte di il codice.
Infine, schiacciare la tua funzionalità in un singolo commit è una buona igiene. Il messaggio di commit dovrebbe includere solo informazioni pertinenti. Molti cambiamenti che avvengono mentre scrivi il codice non sono importanti. Se rinomina un metodo che nessuno ha ancora usato, nessuno deve saperlo. Tuttavia, se si rinomina un metodo in codice già pubblico, si dovrebbe menzionarlo come una modifica potenzialmente inoppugnabile, specialmente nel caso di metodi pubblici.