Changement de git commit message après coup (vu l'absence d'un tiré à partir de la télécommande)

J'ai fait un git commit et suivantes pousser. Je voudrais changer le message de commit. Si je comprends bien, ce n'est pas conseillé parce que quelqu'un pourrait avoir tiré sur le dépôt distant avant de me faire de tels changements. Que faire si je sais que personne n'a tiré?

Est-il un moyen de faire cela?

  • Qu'avez-vous essayé? En supposant que vous savez comment changer le message de commit déjà, et puis essayer de pousser, Git vous dira ce que vous devez faire pour y arriver.
  • Voir la réponse à la question "Comment puis-je modifier un mauvais message de commit dans git (j'ai poussé)?" stackoverflow.com/a/457396/444639
  • Déclarant - Google Question de git commit Rang de n ° 1 !
  • help.github.com/articles/changing-a-commit-message
  • Si vous modifiez la TÊTE commit et push généralement (sans --force), puis de façon surprenante, il n'échoue pas. TÊTE de message de validation est mis à jour avec le changement de commettre Id. Cela signifie que les autres commettent des Id à l'exception de la TÊTE reste intacte. J'ai remarqué ce problème avec git version 2.8.1.
  • Simple et facile pour tous s'engage, non seulement la plus récente: stackoverflow.com/a/5032614/7705712

InformationsquelleAutor K_U | 2012-01-24
  1. 1236

    Changer l'histoire

    Si c'est la plus récente engager, vous pouvez simplement faire ceci:

    git commit --amend

    Cela amène l'éditeur, avec le dernier message de commit et vous permet de modifier le message. (Vous pouvez utiliser -m si vous voulez effacer les anciens messages et utiliser un nouveau.)

    Pression

    Et puis quand vous appuyez, faites ceci:

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

    Ou vous pouvez utiliser le bouton "+":

    git push <repository> +<branch>

    Ou vous pouvez utiliser --force:

    git push --force <repository> <branch>

    Être prudent lors de l'utilisation de ces commandes.

    • Si quelqu'un d'autre a poussé les changements à la même direction générale, vous voulez probablement pour éviter la destruction de ces changements. Le --force-with-lease option est la plus sûre, car il s'arrêtera s'il y a des changements en amont (

    • Si vous ne spécifiez pas la branche explicitement, Git utilisera la valeur par défaut push. Si votre défaut de pousser le réglage est "matching", alors vous pouvez détruire des changements sur plusieurs branches en même temps.

    Tirant /récupération après

    Quelqu'un qui a déjà tiré obtiendrez alors un message d'erreur, et ils auront besoin d'une mise à jour (en supposant qu'ils ne sont pas tous les changements eux-mêmes), en faisant quelque chose comme ceci:

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

    Être prudent lors de l'utilisation de reset --hard. Si vous avez des modifications à la direction générale, ces modifications seront détruits.

    Une remarque sur la modification de l'histoire

    Les données détruites est vraiment juste l'ancien message de commit, mais --force ne le sais pas, et sera heureux de supprimer d'autres données. Alors, pensez à --force comme "je veux détruire les données, et je sais pour sûr que les données sont détruites." Mais lors de la destruction de données commis, vous pouvez souvent de récupérer les vieux s'engage à partir de la reflog—les données sont en fait orphelins au lieu d'détruit (bien que les orphelins commits sont régulièrement supprimés).

    Si vous ne pensez pas que vous êtes de détruire les données, puis de rester loin de --force... les mauvaises choses qui pourrait arriver.

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

    • Être prudent avec ce "fix", comme si ils ont des locaux, unpushed commet ils seront "perdus" (perdu vraiment de sens orphelin, mais leur récupération n'est pas évidente).
    • vous voulez probablement pour spécifier le nom de la branche lorsque vous appuyez --force, sinon vous risquez de pousser encore plus que prévu.
    • Git ne feront que pousser à ce que vous configurez pour pousser.
    • Macaferi: à l'Aide de -m ici ne permet pas de modifier l'ancien message, il ne vous permet de spécifier le nouveau message.
    • oui... juste à expérimenter avec ce droit maintenant. Merci pour le heads up! 🙂
    • Et si je devais commettre l'avant-dernière engager? Pouvais-je faire "git rebase TÊTE^^ -i" et ensuite modifier le premier commit, puis "git push TÊTE^^ --force"?
    • Simplement git push --force sans <référentiel> et <branch> options fonctionne aussi, si vous avez votre en amont de définir.
    • Cette réponse devrait vraiment inclure @SteveBenner note qu'il pousse TOUTES les branches, et vous devez l'utiliser git push --force origin +master (ou quel que soit votre nom de la branche est) ou vous risquez de supprimer des données sur d'autres branches que vous pourriez avoir, mais ne sont pas dans la synchro
    • Dites-vous que git push --force <repository> <branch> pousse à toutes les branches? C'est tout simplement faux. Il ne pousse à la branche que vous spécifiez.
    • J'ai simplement utilisé git push --force-with-lease comme les dépôts et les branches que j'utilise actuellement sont les valeurs par défaut. Devrait fonctionner avec la plupart des gens dans cette situation.
    • n'est-ce pas votre réponse aussi simple que Manish ou est-ce en raison de la possibilité de quelqu'un d'autre a modifié la même direction et nous avons besoin de prendre une approche sécuritaire?(Si la re-re-lecture maintenant je me rends compte de mon downvote était inutile. désolé)
    • Vous devez être prudent lorsque vous utilisez --force, idéalement, vous comprenez ce que les données sont écrasées / détruit lorsque vous l'utilisez. A force de pousser aussi a certaines conséquences si (contrairement à l'OP) quelqu'un a déjà tiré.
    • Pouvez-vous donner un exemple de <repository>? Est-il origin? org/repo? Ou tout simplement repo?
    • C'est le nom distant, par exemple, origin.
    • Est-il normal que le journal de validation sur mon serveur gitlab montre s'engage (et je peux ouvrir les anciens/nouveaux commits et de voir les fichiers modifiés et les anciens/nouveaux messages de commit respectivement sur chaque)? Si mon local git log ne montre pas l'ancien commit (avec message incorrect), juste la façon dont je l'avais prévu! J'avais utilisé git commit --amend suivie par git push --force-with-lease origin my-branch

    InformationsquelleAutor Dietrich Epp
  2. 386

    Il suffit de dire :

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

    et puis

    git push --force
    • Dans mon cas, git push origin <BRANCH-NAME> n'a pas fonctionné, j'ai eu à utiliser git push --force comme expliqué dans la accepté de répondre.
    • cela ne fonctionne pas pour moi. gotta nous git push --force, ou encore le push ne fonctionne pas.
    • Il devrait fonctionner @ahnbizcad, vous pourriez avoir quelques autres remote nom, bien (y)!!
    • il devrait fonctionner. Assurez-vous que le nom de la branche est correct.
    • Il ne fonctionne pas, parce que - comme le QUESTION dit - le commit est déjà PUSHED. Modifier travaille pour les nations unies-poussé s'engage.
    • J'applaudis la simplicité dans votre explication ! Je l'utilise le plus souvent
    • Pour info, si nous avons besoin de changer le message de commit qui a déjà poussé à commettre, nous pouvons le faire que par la solution fournie par @ManishShrivastava. Mais s'il vous plaît noter qu'il permettra de créer un nouveau Commit ID, pour chaque commit modifié. Ainsi, par exemple, si la validation est modifié 3 fois et poussé 3 fois, les 3 différents commettre Id sera généré.
    • Après avoir essayé ceci, j'obtiens cette erreur: remote: To prevent you from losing history, non-fast-forward updates were rejected. remote: Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note remote: about fast-forwards' section of 'git push --help' for details. ` [remote rejeté] maître -> master (pré-recevoir crochet diminué)`
    • J'ai appliqué avec succès ces commandes uniquement après temporairement "déprotéger" ma branche, qui est arrivé sur mon GitLab-projet hébergé. Si vous avez ce problème, avant d'appliquer ces commandes, veuillez vous référer à cette stackoverflow.com/a/32267118/1423345 pour "ôter la protection de" la branche, et vous pouvez "protéger" à nouveau après l'avoir fait en modifiant le message de commit 🙂
    • Pour une raison que dans mon cas, le changement a été repoussée à trois branches, y compris le sien. Heureusement mon changement était petite pour que je puisse obtenir plus d'autres sinon, il aurait été un cauchemar pour moi. La ligne de fond - Penser mille fois avant de faire la commande git push --force

    InformationsquelleAutor Manish Shrivastava
  3. 204

    Risquez d'être en retard à la fête, voici une réponse que je ne vois pas ici.

    Etape 1: git rebase -i HEAD~n faire rebase interactif pour la dernière n s'engage touchés.

    git affichera un éditeur pour gérer les livraisons, les avis de cette commande: # r, reword = use commit, but edit the commit message, c'est exactement ce dont nous avons besoin.

    Etape 2: changement pick à r pour ceux qui s'engage à ce que vous souhaitez mettre à jour le msg.
    Enregistrez et fermez l'éditeur.

    Etape 3: dans la suite de commit des fichiers, mise à jour de la validation msg que vous le souhaitez

    Etape 4: après tout, s'engage msgs sont mis à jour. vous voulez peut-être faire git push -f à la mise à jour de la télécommande.

    • Cela devrait être accepté de répondre, car il donne la possibilité de changer d'autres commits que la plus récente s'engager, contrairement à accepté de répondre. Vous avez sauvé ma journée. Merci!!!!
    • J'obtiens l'erreur invalide en amont de la TÊTE d'~n
    • Choisissez n=3 pour les 3 derniers s'engage à: git rebase -i HEAD~3
    • Si vous modifiez votre rebase "plan" pourtant, il ne s'agit pas de commencer le processus de vous permettant de renommer les fichiers, d'exécuter git rebase --continue. Et si vous voulez changer l'éditeur de texte utilisé pour la session interactive (par exemple à partir de la valeur par défaut vi à nano), exécutez GIT_EDITOR=nano git rebase -i HEAD~n.
    InformationsquelleAutor Jinsong Li
  4. 40

    L'utilisation de ces deux étapes dans la console :

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

    et puis

    git push -f

    Fait 🙂

    • Vous êtes un Jedi. Merci, rien d'autre n'a fonctionné!
    • Simple et de travail. Je pense que ce doit être la réponse choisie
    • Merci pour vos précieux commentaires 🙂
    • Thx, c'Est que les étapes seulement pour amender le dernier commentaire, ou peut-il être utilisé pour les anciens commentaires trop?
    • désolé pour la réponse tardive, ces étapes pour modifier le dernier message de commit.
    • joliment fait, thx @AbdulRizwan, upvoted pour les nettoyer et de réponse claire.

    InformationsquelleAutor Abdul Rizwan
  5. 18

    Il convient de noter que si vous utilisez push --force avec plusieurs refs, ils vont TOUS être modifiés en conséquence. Assurez-vous de payer attention à l'endroit où votre repo git est configuré pour le pousser à. Heureusement, il existe une façon de protéger le processus légèrement, en spécifiant une seule branche de mise à jour. Lire à partir de la git homme pages:

    Noter que --force s'applique à tous les arbitres qui sont poussés, par conséquent, avec
    avec push.défaut de contrepartie ou avec plusieurs pousser
    destinations configurées avec la télécommande.*.poussez peut remplacer les références à d'autres
    que la branche courante (y compris les refs qui sont strictement derrière
    leur homologue distant). À force de pousser pour une seule branche, l'utilisation a +
    en face de la refspec de pousser (e.g git push origin +master à force
    une poussée de la branche master).

    • Très remarque importante.
    • aucun de la force réponses de travail pour moi, parce que je n'ai pas ForcePush autorisations sur le serveur. Au lieu de cela, je veux effectuer un commit qui change un précédent message de commit. Je pourrais écrire "message de commit changé" à qui engagent la section des commentaires.
    InformationsquelleAutor Steve Benner
  6. 11

    Si vous souhaitez modifier une ancienne commettre, pas la dernière, vous aurez besoin d'utiliser rebase commande comme expliqué ici,Github page d'aide , sur la Modifiant le message des anciens ou plusieurs messages de commit section

    InformationsquelleAutor Carlos
  7. 9

    Commande 1.

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

    Puis,

    Commande 2.

    git push origin --force
    InformationsquelleAutor Teo Choong Ping
  8. 3
    git commit --amend

    puis modifier, puis modifier le message dans la fenêtre actuelle. Après cela ne

    git push --force-with-lease
    InformationsquelleAutor Beu
  9. 2

    Une autre option est de créer une autre "errata commettre" (et push) qui fait référence à la commettre l'objet qui contient l'erreur-le nouvel errata commettre fournit également la correction. Un feuillet d'errata commit est un commit avec pas de fond les changements de code, mais un important message de commit -- par exemple, ajouter un caractère d'espace pour votre fichier readme et s'engager à ce que le changement avec l'important message de commit, ou utiliser la commande git option --allow-empty. Il est certainement plus facile et plus sûr que la relocalisation, il ne modifie pas la vrai histoire, et il conserve la branche de l'arbre nettoyer (à l'aide de amend est également un bon choix si vous êtes à la correction la plus récente livraison, mais un errata de validation peut être un bon choix pour les plus âgés s'engage). Ce genre de chose arrive rarement que documenter simplement l'erreur est assez bon. Dans l'avenir, si vous avez besoin de recherche dans un git log pour une fonction de mots clés, l'original (erronée) s'engager à ne peut pas apparaître en raison de la mauvaise mot-clé a été utilisé dans l'original s'engager (à l'origine de la faute de frappe) -- toutefois, le mot-clé apparaît dans l'errata de commettre, qui sera alors de vous diriger à l'origine de commettre, qui avait la typo. Voici un exemple:

    $ git log 
s'engager 0c28141c68adae276840f17ccd4766542c33cf1d 
Auteur: Prénom 
Date: Mercredi 8 Août À 15:55:52 2018 -0600 

Errata de s'engager: 
Ce commit n'a pas de fond de changement de code. 
Cette validation est fourni uniquement à documenter une correction à un précédent message de commit. 
Ceci se rapporte à l'objet commit e083a7abd8deb5776cb304fa13731a4182a24be1 
Incorrect Original message de commit: 
Changé de couleur de fond rouge 
Correction (*modifier en surbrillance*): 
Changé de couleur de fond *bleu* 

s'engager 032d0ff0601bff79bdef3c6f0a02ebfa061c4ad4 
Auteur: Prénom 
Date: Mercredi 8 Août À 15:43:16 2018 -0600 

Certains intermédiaires message de commit 

s'engager e083a7abd8deb5776cb304fa13731a4182a24be1 
Auteur: Prénom 
Date: Mercredi 8 Août À 13:31:32 2018 -0600 

Changé de couleur de fond rouge
    • rob, ça a l'air prometteur. pouvez-vous afficher les commandes nécessaires pour faire un "errata s'engager". seulement ce post s'affiche dans google sur ces termes.
    • Un “errata commettre” est tout simplement normal de s'engager avec un message qui fait référence à la précédente erroné de s'engager, de documentation et de fournir une correction pour l'erreur précédente. git commit -m “fixed feature A” (Supposons git cela donne un commit ID de e3ab7312... ... (plus tard, vous vous rendez compte de votre message incorrect donc maintenant faire un pas sans conséquence modification à un fichier comme l'ajout d'un espace pour le fichier readme, ou utiliser le —allow-empty git option) ... git commit -m “Errata commit for previous commit e3ab7312... original message should have been ‘fixed feature *B*’ ‘’
    • ...si plus tard vous avez besoin de rechercher la commande git log pour les références à la fonction “B”, les errata de la validation, mais l'errata message de commit contient une référence à l'origine commettre ID qui offre une traçabilité complète. BTW le terme “errata commettre” n'a rien de spécial (il n'y a pas de “errata” commande ni option dans git)...c'est juste mon terminologie pour une normale de commettre, qui fournit une correction à une précédente livraison qui a eu une erreur/faute de frappe.
    • rob, qui a très bien fonctionné. J'ai été en mesure d'ajouter un nouveau vide s'engager avec la description correcte, que les points à l'origine de valider, à l'aide de la SHA. maintenant, les deux sont indiqués dans mon git "chaîne" pour les modules. merci!
    InformationsquelleAutor rob_7cc
  10. 1

    Cela fonctionne pour moi, assez fine,

    git checkout origine/branchname

    si vous êtes déjà dans la branche puis c'est mieux de le faire tirer ou de rebase

    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 le souhaitez pour ouvrir l'éditeur de texte, puis utiliser

    git commit --amend

    Je préfère utiliser l'éditeur de texte si vous avez de nombreux commentaires. Vous pouvez configurer votre préféré éditeur de texte avec la commande

    git config --global core.editor your_preffered_editor_here

    De toute façon, lorsque vous avez terminé de changer le message de commit, le sauvegarder et quitter

    puis exécutez

    git push --force

    Et vous avez terminé

    InformationsquelleAutor Hasasn
  11. 0

    de l'information supplémentaire pour le même problème si vous utilisez bitbucket pipeline

    éditer votre message

    git commit --amend

    pousser à le rompre 

    git push --force <repository> <branch>

    puis ajouter l'option --force pour pousser votre commande sur le pipeline 

    git ftp push --force

    Cela permettra de supprimer votre précédente livraison(s) et pousser votre.

    enlevez l'option --force après la première poussée

    je l'ai essayé sur bitbucket pipeline et sa fonctionne bien

    InformationsquelleAutor Abdallah Awwad Alkhwaldah