Dopo aver scritto alcune commit, molto spesso git rebase -i su di esse, per testarle, se necessario dividerle, prendere le parti da un commit e squash verso un altro, più appropriato.
Ma c'è un problema. Dite, oggi sto cercando un bug, che stanno provocando 5 recenti commit. Interagisco interattivamente sull'ultimo noto al lavoro (sopporta me, non usando git bisect per un motivo). Il prossimo commit introduce il bug, ma è un grosso casino un codice non correlato.
Quindi I git reset HEAD~ e quindi forma diversi commit logici internamente.
Ecco il problema. Non so quale sia il primo commit problematico. Quindi seleziono edit per tutti i commit durante il ribasso. Dopo che ho finito con il commit problematico, ho un paio di commit in passato, che vorrei testare ulteriormente.
Al momento, faccio git rebase --continue molte volte, finché il rebase non è completo, quindi rebase in modo interattivo di nuovo. Questo ha alcuni problemi:
- È noioso. Per lo meno, vorrei un comando che rebase in cima al ramo, saltando tutti i
editdichiarato commit. - Neverending si unisce. Ho bisogno di unirmi spesso, e preferirei prima fare il lavoro significativo di dividere il commit originale, e solo dopo che
git commit --ammendquest'ultimo commette per essere compatibile con la storia modificata.
TL; DR;
Come posso ottenere questa traversata bidirezionale su un ramo, mentre allo stesso tempo, creando, rimuovendo e modificando i commit? Oppure questo flusso di lavoro è concettualmente sbagliato?