Ho la seguente situazione: Ho effettuato alcune commit al mio repository locale, e quindi un'enorme fusione di un altro ramo (~ 150 commit) nel master - aveva molti conflitti in esso.Come si usa git rebase -i dopo git merge senza rovinare le cose?
Ora, voglio spostare un commit che ho fatto prima dell'unione per essere dopo di esso prima di premere.
Normalmente, vorrei usare "rebase -i" per questo.
Purtroppo, il comportamento predefinito è quello di rompere l'uno-merge-commit ho fatto che in realtà aggiunge 150 più impegna a padroneggiare in commit separati (capisco è come se avessi usato rebase invece di merge per cominciare) - che è un cattivo comportamento per me per diversi motivi.
Ho scoperto il flag "-p" per rebase, che conserva le unioni e ne sono rimasto molto contento. Sfortunatamente, questo ha applicato di nuovo la stessa unione, e ha dimenticato tutto il mio duro lavoro nella risoluzione dei conflitti. Di nuovo - cattivo comportamento!
C'è una soluzione per quello che voglio? Utilizzare rebase -i dopo l'unione per riordinare o modificare commit specifici senza dover ripetere le operazioni di post-merge?
Grazie!
Hai dato un'occhiata a [git rerere] (http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html)? –
'git rerere' non può aiutarti ora, dal momento che registra la risoluzione del conflitto quando si effettua l'unione ... tranne che c'è uno script chiamato [rerere-train.sh] (http://git.kernel.org/? p = git/git.git; a = blob; f = contrib/rerere-train.sh; hb = HEAD) nella directory contrib di git che "avvia" il database rerere da commit di merge già effettuati. – Cascabel