Voglio modificare un messaggio di commit più in profondità nella storia e ho spinto molti nuovi commit.
Come posso modificare il messaggio di commit? È possibile?
Voglio modificare un messaggio di commit più in profondità nella storia e ho spinto molti nuovi commit.
Come posso modificare il messaggio di commit? È possibile?
Risposte:
Il messaggio di Linus Torvalds potrebbe rispondere alla tua domanda:
Modifica / modifica i vecchi messaggi di commit
Risposta breve: non puoi (se premuto).
extract (Linus si riferisce a BitKeeper come BK):
Nota a margine, solo per interesse storico: in BK potresti.
E se ci sei abituato (come ero io) era davvero abbastanza pratico. Vorrei applicare una patch-bomb di Andrew, notare che c'era qualcosa che non andava e modificarlo prima di espellerlo.
Avrei potuto fare lo stesso con Git. Sarebbe stato abbastanza facile fare in modo che il messaggio di commit non facesse parte del nome e garantire comunque che la cronologia non fosse toccata, e consentire la "correzione dei commenti in seguito".
Ma non l'ho fatto.
Parte di essa è puramente "coerenza interna". Git è semplicemente un sistema più pulito grazie a tutto ciò che è protetto da SHA1 e tutti gli oggetti trattati allo stesso modo, indipendentemente dal tipo di oggetto. Sì, ci sono quattro diversi tipi di oggetti, e sono tutti davvero diversi, e non possono essere usati allo stesso modo, ma allo stesso tempo, anche se la loro codifica potrebbe essere diversa su disco, concettualmente funzionano tutti esattamente lo stesso.
Ma la coerenza interna non è in realtà una scusa per essere poco flessibile, e chiaramente sarebbe molto flessibile se potessimo solo correggere gli errori dopo che si sono verificati. Quindi non è un argomento davvero forte.
La vera ragione per cui git non ti consente di cambiare il messaggio di commit finisce per essere molto semplice: in questo modo, puoi fidarti dei messaggi. Se hai permesso alle persone di modificarle in seguito, i messaggi non sono intrinsecamente molto affidabili.
Per essere completo, è possibile riscrivere la cronologia di commit locale al fine di riflettere ciò che si desidera, come suggerito da Sykora (con alcuni rebase e reset --hard, gasp!)
Tuttavia, una volta che si pubblica la vostra storia rivisto ancora una volta (con una git push origin +master:master
, il +
segno costringendo la spinta a verificarsi, anche se non si traduca in un "fast-forward" commit) ... si potrebbe ottenere in qualche guaio .
Estratto da questa altra domanda SO:
In realtà una volta ho spinto con --force nel repository git.git e sono stato sgridato da Linus BIG TIME. Creerà molti problemi per altre persone. Una semplice risposta è "non farlo".
Attualmente un sostituto git potrebbe fare il trucco.
Nel dettaglio: creare un ramo di lavoro temporaneo
git checkout -b temp
Ripristinare il commit per sostituire
git reset --hard <sha1>
Modifica il commit con il messaggio giusto
git commit --amend -m "<right message>"
Sostituisci il vecchio commit con quello nuovo
git replace <old commit sha1> <new commit sha1>
torna al ramo dove eri
git checkout <branch>
rimuovere il ramo temporaneo
git branch -D temp
spingere
guess
fatto.
È possibile utilizzare git rebase -i
(contro il ramo da cui si è ramificato) 'i' per interattivo.
Sostituisci il pick
prossimo con il commento di commit che desideri modificare r
(o reword
), salva ed esci e, facendo ciò, sarai in grado di effettuare la modifica.
git push
ancora una volta e il gioco è fatto!
-p
argomento di rebase
quali p
riserve si fondono.
Supponiamo di avere un albero come questo:
dd2e86 - 946992 - 9143a9 - a6fd86 - 5a6057 [master]
Innanzitutto, checkout
un ramo temporaneo:
git checkout -b temp
Sul temp
ramo, reset --hard
a un commit che si desidera modificare il suo messaggio (ad esempio, quel commit è 946992
):
git reset --hard 946992
Utilizzare amend
per modificare il messaggio:
git commit --amend -m "<new_message>"
Dopodiché l'albero apparirà così:
dd2e86 - 946992 - 9143a9 - a6fd86 - 5a6057 [master]
\
b886a0 [temp]
Quindi, cherry-pick
tutto il commit che precede 946992
da master
a temp
e li commette, utilizzare amend
se si desidera modificare anche i loro messaggi:
git cherry-pick 9143a9
git commit --amend -m "<new_message>
...
git cherry-pick 5a6057
git commit --amend -m "<new_message>
L'albero ora appare così:
dd2e86 - 946992 - 9143a9 - a6fd86 - 5a6057 [master]
\
b886a0 - 41ab2c - 6c2a3s - 7c88c9 [temp]
Ora forza spingi il ramo temporaneo sul telecomando:
git push --force origin temp:master
Il passaggio finale, eliminare il ramo master
su locale, git fetch origin
per estrarre il ramo master
dal server, quindi passare al ramo master
ed eliminare il ramo temp
.
Ora sia il tuo locale che il tuo remoto avranno tutti i messaggi aggiornati.
Nel nostro negozio, ho introdotto la convenzione di aggiungere tag annotati con nome riconoscibile per eseguire il commit con messaggi errati e utilizzare l'annotazione come sostituzione.
Anche se questo non aiuta le persone che eseguono comandi "git log" casuali, ci fornisce un modo per correggere i riferimenti errati di tracker dei bug nei commenti e tutti i miei strumenti di compilazione e rilascio comprendono la convenzione.
Questa ovviamente non è una risposta generica, ma potrebbe essere qualcosa che la gente può adottare all'interno di comunità specifiche. Sono sicuro che se questo viene utilizzato su una scala più ampia, potrebbe sorgere una sorta di supporto in porcellana, alla fine ...
(Da http://git.or.cz/gitwiki/GitTips#head-9f87cd21bcdf081a61c29985604ff4be35a5e6c0 )
Come cambiare si impegna più a fondo nella storia
Poiché la cronologia in Git è immutabile, la correzione di qualsiasi cosa tranne il commit più recente (commit che non è la diramazione) richiede che la cronologia venga riscritta dal commit modificato e inoltra.
È possibile utilizzare StGIT per questo, inizializzare il ramo se necessario, annullare il commit fino al commit che si desidera modificare, pop su di esso se necessario, apportare una modifica quindi aggiornare la patch (con l'opzione -e se si desidera correggere il messaggio di commit), quindi premere tutto e stg si impegnano.
Oppure puoi usare rebase per farlo. Crea un nuovo ramo temporaneo, riavvolgi il commit che vuoi modificare usando git reset --hard, cambia quel commit (sarebbe in cima alla testa corrente), quindi rinnova il ramo in cima al commit modificato, usando git rebase --onto.
Oppure puoi usare git rebase --interactive, che consente varie modifiche come riordinare le patch, comprimere, ...
Penso che dovrebbe rispondere alla tua domanda. Tuttavia, tieni presente che se hai trasferito il codice in un repository remoto e le persone ne hanno tratto, questo rovinerà la loro cronologia del codice, così come il lavoro che hanno svolto. Quindi fallo con attenzione.