Come posso modificare un messaggio di commit errato in git (che ho spinto)?

Voglio modificare un messaggio di commit più in profondità nella storia e ho spinto molti nuovi commit.

Come posso cambiare il messaggio di commit? È ansible?

Il messaggio di Linus Torvalds potrebbe rispondere alla tua domanda:

Modifica / modifica vecchi messaggi di commit

Risposta breve: non puoi (se premuto).


estratto (Linus si riferisce a BitKeeper come BK):

Nota a margine, solo per interesse storico: in BK potevi.

E se ci sei abituato (come lo ero io) era davvero abbastanza pratico. Applicherei una bomba-patch da Andrew, noterò che qualcosa non andava e basta modificarlo prima di spingerlo fuori.

Avrei potuto fare lo stesso con Git. Sarebbe stato abbastanza facile far sì che solo il messaggio di commit non fosse parte del nome, e comunque garantire che la cronologia fosse intatta, e consentire la cosa “aggiusta i commenti dopo”.

Ma non l’ho fatto.

Parte di esso è puramente “coerenza interna”. Git è semplicemente un sistema più pulito grazie al fatto che tutto è protetto da SHA1 e che tutti gli oggetti vengono trattati allo stesso modo, indipendentemente dal tipo di object. Sì, ci sono quattro diversi tipi di oggetti, e sono tutti molto diversi, e non possono essere usati allo stesso modo, ma allo stesso tempo, anche se la loro codifica potrebbe essere diversa sul disco, concettualmente funzionano tutti esattamente lo stesso.

Ma la coerenza interna non è davvero una scusa per essere inflessibile, e chiaramente sarebbe molto flessibile se potessimo correggere gli errori una volta accaduti. Quindi non è un argomento molto forte.

Il vero motivo per cui git non ti permette di cambiare il messaggio di commit è molto semplice: in questo modo puoi fidarti dei messaggi. Se hai permesso alle persone di cambiarle in seguito, i messaggi non sono molto affidabili.


Per essere completo, è ansible riscrivere la cronologia dei commit locale per riflettere ciò che si desidera, come suggerito da sykora (con alcuni rebase e reset –hard, gasp!)

Tuttavia, dopo aver pubblicato di nuovo la cronologia revisionata (con git push origin +master:master , il segno + che forza la richiesta di push, anche se non risulta in un commit “avanti veloce”) … potresti mettiti nei guai

Estratto da questa altra domanda SO:

In realtà una volta ho spinto con –force per git.git repository e sono stato sgridato da Linus BIG TIME. Creerà molti problemi per le altre persone. Una risposta semplice è “non farlo”.

Attualmente un git replace potrebbe fare il trucco.

In dettaglio: crea un ramo di lavoro temporaneo

 git checkout -b temp 

Ripristina il commit da sostituire

 git reset --hard  

Modifica il commit con il messaggio giusto

 git commit --amend -m "" 

Sostituisci il vecchio commit con quello nuovo

 git replace   

torna al ramo dove eri

 git checkout  

rimuovere il ramo temp

 git branch -D temp 

spingere

 guess 

fatto.

Puoi usare git rebase -i (contro il ramo da cui sei derivato) ‘i’ per interattivo.

Sostituisci il pick accanto al commento di commit che desideri modificare con r (o reword ), salva ed esci e, dopo averlo fatto, sarai in grado di effettuare la modifica.

git push ancora una volta e il gioco è fatto!

Supponiamo di avere un albero come questo:

 dd2e86 - 946992 - 9143a9 - a6fd86 - 5a6057 [master] 

Innanzitutto, controlla un ramo temporaneo:

 git checkout -b temp 

Sul ramo temp , reset --hard ad un commit che vuoi modificare il suo messaggio (ad esempio, il commit è 946992 ):

 git reset --hard 946992 

Usa amend per cambiare il messaggio:

 git commit --amend -m "" 

Dopo che l’albero sarà simile a questo:

 dd2e86 - 946992 - 9143a9 - a6fd86 - 5a6057 [master] \ b886a0 [temp] 

Quindi, cherry-pick tutti gli impegni precedenti a 946992 da master a temp e 946992 commit, utilizza amend se desideri modificare anche i loro messaggi:

 git cherry-pick 9143a9 git commit --amend -m " ... git cherry-pick 5a6057 git commit --amend -m " 

L’albero ora si presenta così:

 dd2e86 - 946992 - 9143a9 - a6fd86 - 5a6057 [master] \ b886a0 - 41ab2c - 6c2a3s - 7c88c9 [temp] 

Ora forza spingere il ramo temporaneo a remoto:

 git push --force origin temp:master 

Il passo finale, eliminare il master ramo su local, git fetch origin per estrarre il master ramo dal server, quindi passare al master ramo e cancellare il branch temp .

Ora sia il tuo locale che il tuo remoto avranno tutti i messaggi aggiornati.

Presso il nostro negozio, ho introdotto la convenzione di aggiungere tag annotati riconoscibilmente denominati per eseguire commit con messaggi errati e utilizzare l’annotazione come sostituzione.

Anche se questo non aiuta le persone che eseguono comandi casuali di “git log”, ci fornisce un modo per correggere i riferimenti errati dei tracker nei commenti, e tutti i miei strumenti di compilazione e rilascio comprendono la convenzione.

Ovviamente questa non è una risposta generica, ma potrebbe essere qualcosa che le persone possono adottare all’interno di specifiche comunità. Sono sicuro che se questo viene usato su una scala più grande, una sorta di supporto in porcellana potrebbe apparire, alla fine …

(Da http://git.or.cz/gitwiki/GitTips#head-9f87cd21bcdf081a61c29985604ff4be35a5e6c0 )

Come cambiare i commit più in profondità nella storia

Poiché la cronologia in Git è immutabile, la correzione di tutto tranne il commit più recente (commit che non è branch head) richiede che la cronologia venga riscritta dal commit modificato e inoltrato.

È ansible utilizzare StGIT per questo, inizializzare il branch, se necessario, senza commit fino al commit che si desidera modificare, poparlo se necessario, apportare una modifica e aggiornare patch (con l’opzione -e se si desidera correggere il messaggio di commit), quindi premere tutto e stg commit.

Oppure puoi usare rebase per farlo. Crea un nuovo ramo temporaneo, riavvolgilo nel commit che vuoi cambiare usando git reset –hard, cambia quel commit (sarebbe top of current head), quindi rebase branch su top del commit modificato, usando git rebase –onto.

Oppure puoi usare git rebase –interactive, che consente varie modifiche come il riordino delle patch, il collasso, …

Penso che dovrebbe rispondere alla tua domanda. Tuttavia, tieni presente che se hai trasferito il codice su un repository remoto e le persone ne hanno ricavato, questo rovinerà le loro storie di codice e il lavoro che hanno svolto. Quindi fallo con attenzione.