Modification du message de validation git après push (étant donné que personne n'a tiré de la télécommande)


983

J'ai fait un git commit et un push ultérieur. Je voudrais changer le message de validation. Si je comprends bien, ce n'est pas conseillé car quelqu'un a pu se retirer du référentiel distant avant d'effectuer de telles modifications. Et si je sais que personne n'a tiré?

Y a-t-il un moyen de faire cela?


Qu'as-tu essayé? En supposant que vous savez déjà comment modifier le message de validation, puis essayez de pousser, Git vous dira ce que vous devez faire pour y arriver.
Andrew Marshall

1
Voir la réponse à la question "Comment modifier un message de validation incorrect dans git (j'ai poussé)?" stackoverflow.com/a/457396/444639
Mike Rylander

4
Le déclarer - Google Question de git commit Rang no 1!
Manish Shrivastava


Si vous modifiez le commit HEAD et poussez généralement (sans --force), il n'est pas étonnant que cela échoue. Le message de validation HEAD est mis à jour avec l'ID de validation modifié. Cela signifie que les autres ID de validation, à l'exception de HEAD, restent intacts. J'ai remarqué ce comportement avec la version git 2.8.1.
irsis

Réponses:


1375

Changer l'histoire

S'il s'agit du commit le plus récent, vous pouvez simplement le faire:

git commit --amend

Cela affiche l'éditeur avec le dernier message de validation et vous permet de modifier le message. (Vous pouvez utiliser -msi vous souhaitez effacer l'ancien message et en utiliser un nouveau.)

Pousser

Et puis quand vous poussez, faites ceci:

git push --force-with-lease <repository> <branch>

Ou vous pouvez utiliser "+":

git push <repository> +<branch>

Ou vous pouvez utiliser --force:

git push --force <repository> <branch>

Soyez prudent lorsque vous utilisez ces commandes.

  • Si quelqu'un d'autre a poussé les modifications vers la même branche, vous souhaiterez probablement éviter de détruire ces modifications. L' --force-with-leaseoption est la plus sûre, car elle sera abandonnée en cas de modifications en amont (

  • Si vous ne spécifiez pas la branche explicitement, Git utilisera les paramètres push par défaut. Si votre paramètre de push par défaut est "correspondant", vous pouvez détruire les modifications sur plusieurs branches en même temps.

Tirer / récupérer ensuite

Quiconque a déjà tiré recevra maintenant un message d'erreur, et il devra mettre à jour (en supposant qu'il n'apporte aucune modification lui-même) en faisant quelque chose comme ceci:

git fetch origin
git reset --hard origin/master # Loses local commits

Soyez prudent lors de l'utilisation reset --hard. Si vous avez modifié la branche, ces modifications seront détruites.

Une note sur la modification de l'historique

Les données détruites ne sont en fait que l'ancien message de validation, mais --forcene le savent pas, et supprimeront également volontiers d'autres données. Pensez donc --forceà "Je veux détruire les données, et je sais avec certitude quelles données sont détruites." Mais lorsque les données détruites sont validées, vous pouvez souvent récupérer les anciennes validations du reflog - les données sont en fait orphelines au lieu d'être détruites (bien que les validations orphelines soient périodiquement supprimées).

Si vous ne pensez pas que vous détruisez des données, restez à l'écart de --force... de mauvaises choses pourraient se produire .

C'est pourquoi --force-with-leaseest un peu plus sûr.


13
Soyez prudent avec ce "correctif", comme s'ils avaient des commits locaux non poussés, ils seront "perdus" ( perdus signifiant vraiment orphelins , mais les récupérer n'est pas évident).
Andrew Marshall

1
vous voudrez probablement spécifier le nom de la branche lorsque vous appuyez sur --force, sinon vous pouvez pousser plus que prévu.
user693960

1
@ user693960: Git ne poussera que ce que vous configurez pour pousser.
Dietrich Epp

10
Tout simplement git push --forcesans les options <repository> et <branch> fonctionne aussi, si vous avez votre configuration en amont.
ahnbizcad

2
Pouvez-vous en donner un exemple <repository>? C'est ça origin? org/repo? Ou tout simplement repo?
MikeSchinkel

440

Dis le :

git commit --amend -m "New commit message"

et alors

git push --force

8
Dans mon cas git push origin <BRANCH-NAME>ne fonctionnait pas, j'ai dû utiliser git push --forcecomme expliqué dans la réponse acceptée.
Gabriel

1
ça ne marche pas pour moi. dois nous git push --force, sinon la poussée ne passe pas.
ahnbizcad

4
@ahnbizcad, cela devrait fonctionner. Assurez-vous simplement que le nom de la branche est correct.
William

3
J'encourage la simplicité de votre explication! Je l'utilise plus que souvent
Vasikos

3
J'ai appliqué ces commandes avec succès uniquement après avoir "déprotégé" temporairement ma branche, ce qui s'est produit sur mon projet hébergé par GitLab. Si vous rencontrez ce problème, avant d'appliquer ces commandes, veuillez vous référer à ce stackoverflow.com/a/32267118/1423345 pour "déprotéger" la branche, et vous pouvez la "protéger" à nouveau après avoir modifié le message de validation :)
John

262

Pour modifier un commit autre que le plus récent:

Étape 1 : git rebase -i HEAD~npour effectuer un rebase interactif pour les dernières validations naffectées. (c.-à-d. si vous voulez changer un message de validation, 3 validations reviennent, faites git rebase -i HEAD~3)

git affichera un éditeur pour gérer ces validations, notez cette commande:

#  r, reword = use commit, but edit the commit message

c'est exactement ce dont nous avons besoin!

Étape 2 : passezpick à rpour les validations que vous souhaitez mettre à jour le message. Ne vous embêtez pas à changer le message de validation ici, il sera ignoré. Vous le ferez à l'étape suivante. Enregistrez et fermez l'éditeur.

Notez que si vous modifiez votre «plan» de rebase mais qu'il ne commence pas le processus de vous permettre de renommer les fichiers, exécutez:

git rebase --continue

Si vous souhaitez modifier l'éditeur de texte utilisé pour la session interactive (par exemple, du vi par défaut à nano), exécutez:

GIT_EDITOR=nano git rebase -i HEAD~n

Étape 3 : Git fera apparaître un autre éditeur pour chaque révision que vous avez mise ravant. Mettez à jour le message de validation à votre guise, puis enregistrez et fermez l'éditeur.

Étape4 : Une fois tous les commits, les msgs sont mis à jour. vous voudrez peut-être faire git push -fpour mettre à jour la télécommande.


21
Cette réponse doit être acceptée car elle donne la possibilité de modifier d'autres validations que la validation la plus récente, contrairement à la réponse acceptée. Tu m'as sauvé la journée. Je vous remercie!
xZero

1
Choisissez n = 3 pour les 3 derniers commits:git rebase -i HEAD~3
HeikoS

Si vous modifiez votre «plan» de rebase, il ne démarre pas le processus de vous permettre de renommer les fichiers, exécutez git rebase --continue. Et si vous voulez changer l'éditeur de texte utilisé pour la session interactive (par exemple , la valeur par défaut vià nano), exécutez GIT_EDITOR=nano git rebase -i HEAD~n.
Jamie Birch

J'ai modifié cela pour ajouter un peu plus d'informations. S'il vous plaît, jetez un oeil. C'était la réponse à ce que je voulais faire, mais je l'ai fait défiler car il n'avait pas l'en-tête.
Kip

J'ai fait une suggestion de modification pour mettre le commentaire utile de @JamieBirch dans la réponse, je voudrais peut-être le revoir.
Notts90 prend en charge Monica

44

Utilisez ces deux étapes dans la console:

git commit --amend -m "new commit message"

et alors

git push -f

Terminé :)


Thx, est-ce que les étapes sont uniquement pour modifier le dernier commentaire ou peut-il être utilisé pour les commentaires plus anciens aussi?
Jay

@Jay désolé pour une réponse tardive, ces étapes uniquement pour modifier le dernier message de validation.
Abdul Rizwan

19

Il convient de noter que si vous utilisez push --forceplusieurs références, elles seront TOUTES modifiées en conséquence. Assurez-vous de faire attention à l'endroit où votre dépôt git est configuré pour pousser. Heureusement, il existe un moyen de protéger légèrement le processus, en spécifiant une seule branche à mettre à jour. Lisez les pages de manuel de git:

Notez que --force s'applique à toutes les références qui sont poussées, donc l'utiliser avec push.default défini sur correspondant ou avec plusieurs destinations push configurées avec remote. *. Push peut écraser les références autres que la branche actuelle (y compris les références locales qui sont strictement derrière leur homologue distant). Pour forcer un push sur une seule branche, utilisez un + devant la refspec pour pousser (par exemple git push origin + master pour forcer un push sur la branche master).


3
Note très importante.
peterh

aucune des réponses forcées ne fonctionne pour moi, car je n'ai pas d'autorisations ForcePush sur le serveur. Au lieu de cela, je souhaite effectuer une validation qui modifie un message de validation précédent. Je pourrais écrire "message de commit modifié" dans la section commentaire de ce commit.
nurettin

11

Si vous souhaitez modifier une ancienne COMMIT pas le dernier, vous devrez utiliser la rebasecommande comme expliqué ici, page d'aide Github , le modifiant le message de plus ou de plusieurs commits section


11

Commande 1 .

git commit --amend -m "New and correct message"

Alors,

Commande 2 .

git push origin --force

8
git commit --amend

puis modifiez et modifiez le message dans la fenêtre actuelle. Après cela,

git push --force-with-lease

2

Une autre option consiste à créer un "commit d'errata" (et push) supplémentaire qui référence l'objet de commit qui contient l'erreur - le nouveau commit d'errata fournit également la correction. Un commit d'errata est un commit sans modification substantielle de code mais un message de commit important - par exemple, ajoutez un caractère espace à votre fichier readme et validez ce changement avec le message de commit important, ou utilisez l'option git --allow-empty. C'est certainement plus facile et plus sûr que le rebasage, il ne modifie pas le véritable historique et il maintient l'arborescence des branches propre (en utilisantamendest également un bon choix si vous corrigez le commit le plus récent, mais un commit d'errata peut être un bon choix pour les commits plus anciens). Ce genre de chose arrive si rarement qu'il suffit de simplement documenter l'erreur. À l'avenir, si vous devez rechercher dans un journal git un mot clé de fonctionnalité, le commit d'origine (erroné) peut ne pas apparaître car le mauvais mot clé a été utilisé dans ce commit d'origine (la faute de frappe d'origine) - cependant, le mot clé apparaîtra dans l'errata commit qui vous dirigera ensuite vers le commit d'origine qui avait la faute de frappe. Voici un exemple:

$ git log
valider 0c28141c68adae276840f17ccd4766542c33cf1d
Auteur: First Last 
Date: mer 8 août 15:55:52 2018 -0600

    Validation d'errata:
    Ce commit n'a pas de changement de code substantiel.
    Cette validation est fournie uniquement pour documenter une correction d'un message de validation précédent.
    Cela concerne l'objet de validation e083a7abd8deb5776cb304fa13731a4182a24be1
    Message de validation incorrect d'origine:
        Couleur d'arrière-plan changée en rouge
    Correction (* changement mis en évidence *):
        Couleur d'arrière-plan changée en * bleu *

commit 032d0ff0601bff79bdef3c6f0a02ebfa061c4ad4
Auteur: First Last 
Date: mer 8 août 15:43:16 2018 -0600

    Un message de validation provisoire

commit e083a7abd8deb5776cb304fa13731a4182a24be1
Auteur: First Last 
Date: mer.8 août 13:31:32 2018 -0600

    Couleur d'arrière-plan changée en rouge

rob, cela semble prometteur. pouvez-vous montrer les commandes nécessaires pour faire un "commit d'errata". seul ce post apparaît dans google dans ces conditions.
Jim

1
Un «commit d'errata» est simplement un commit normal avec un message qui fait référence au commit erroné précédent, documentant et fournissant une correction pour l'erreur précédente. git commit -m “fixed feature A”(Supposons que git lui attribue un ID de validation e3ab7312 ... ... (plus tard, vous vous rendez compte que votre message était incorrect, alors apportez maintenant une modification sans conséquence à un fichier comme l'ajout d'un espace au fichier Lisezmoi, ou utilisez l' —allow-emptyoption git). .. git commit -m “Errata commit for previous commit e3ab7312... original message should have been ‘fixed feature *B*’'' '
rob_7cc

1
... si vous avez besoin ultérieurement de rechercher dans le journal git des références à la «fonctionnalité B», la validation d'errata apparaîtra, mais le message de validation d'errata contient une référence à l'ID de validation d'origine qui fournit une traçabilité complète. BTW, le terme "errata commit" n'a rien de spécial (il n'y a pas de commande "errata" ni d'option dans git) ... c'est juste ma terminologie pour un commit normal qui fournit une correction à un commit précédent qui avait une erreur / faute de frappe.
rob_7cc

rob, cela a très bien fonctionné. J'ai pu ajouter un nouveau commit vide avec la description correcte, qui pointe vers le commit d'origine, en utilisant le SHA. maintenant, les deux sont affichés dans ma «chaîne git» pour les modules. Merci!
Jim

Je suis content que cela ait fonctionné pour vous. J'utilise la même technique pour corriger les erreurs dans les messages de validation. Comme alternative, j'ai récemment découvert que git notes cela servirait le même but qu'un "commit d'errata". Ajoutez simplement une note à un commit précédent pour annoter ou corriger toute erreur dans le message de commit: https://git-scm.com/docs/git-notes
rob_7cc

0

Cela fonctionne très bien pour moi,

git checkout origin / branchname

si vous êtes déjà en succursale, il vaut mieux tirer ou rebaser

git pull

ou

git -c core.quotepath=false fetch origin --progress --prune

Plus tard, vous pouvez simplement utiliser

git commit --amend -m "Your message here"

ou si vous aimez ouvrir l'éditeur de texte, utilisez

git commit --amend

Je préférerai utiliser l'éditeur de texte si vous avez de nombreux commentaires. Vous pouvez définir votre éditeur de texte préféré avec la commande

git config --global core.editor your_preffered_editor_here

Quoi qu'il en soit, lorsque vous avez terminé de modifier le message de validation, enregistrez-le et quittez

puis exécutez

git push --force

Et tu as fini


0

des informations supplémentaires pour le même problème si vous utilisez le pipeline bitbucket

éditez votre message

git commit --amend

pousser vers le serveur

git push --force <repository> <branch>

puis ajoutez --force à votre commande push sur le pipeline

git ftp push --force

Cela supprimera vos engagements précédents et poussera votre engagement actuel.

retirer le --force après la première poussée

je l'ai essayé sur le pipeline bitbucket et son bon fonctionnement

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.