Modification du message de validation de git après la diffusion (étant donné que personne n’a été retiré de la télécommande)

J’ai fait un git commit et une poussée ultérieure. Je voudrais changer le message de validation. Si je comprends bien, cela est déconseillé car quelqu’un peut avoir retiré du référentiel distant avant de procéder à de telles modifications. Et si je sais que personne n’a tiré?

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

Changer l’histoire

Si c’est la validation la plus récente, vous pouvez simplement faire ceci:

git commit --amend 

Cela fait apparaître l’éditeur avec le dernier message de validation et vous permet de modifier le message. (Vous pouvez utiliser -m si vous voulez effacer l’ancien message et en utiliser un nouveau.)

En poussant

Et puis quand vous poussez, faites ceci:

 git push --force-with-lease   

Ou vous pouvez utiliser “+”:

 git push  + 

Ou vous pouvez utiliser --force :

 git push --force   

Soyez prudent lorsque vous utilisez ces commandes.

  • Si quelqu’un d’autre a poussé des modifications vers la même twig, vous souhaiterez probablement éviter de détruire ces modifications. L’option --force-with-lease est la plus sûre, car elle annulera les modifications en amont (

  • Si vous ne spécifiez pas explicitement la twig, Git utilisera les parameters push par défaut. Si votre paramètre push par défaut est “correspondant”, vous pouvez détruire les modifications sur plusieurs twigs en même temps.

Tirer / chercher après

Tous ceux qui ont déjà tiré un message d’erreur, et ils devront mettre à jour (en supposant qu’ils n’apportent aucun changement eux-mêmes) en faisant quelque chose comme ceci:

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

Soyez prudent lorsque vous utilisez reset --hard . Si vous modifiez la twig, ces modifications seront détruites.

Une note sur la modification de l’historique

Les données détruites ne sont en réalité que l’ancien message de validation, mais --force ne le sait pas et supprimera volontiers d’autres données. Alors, pensez à --force comme “Je veux détruire des 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 d’anciens commits du renvoi – les données sont en réalité orphelines au lieu d’être détruites (bien que les validations orphelines soient périodiquement supprimées).

Si vous ne croyez pas que vous détruisez des données, restz loin de --force … de mauvaises choses pourraient se produire .

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

Dis le :

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

et alors

 git push --force 

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

Etape 1 : git rebase -i HEAD~n pour faire un rebase interactif pour les n derniers commits affectés.

git va ouvrir un éditeur pour gérer ces commits, notez cette commande: # r, reword = use commit, but edit the commit message , c’est exactement ce dont nous avons besoin.

Etape 2 : changez le pick de r pour les commits que vous souhaitez mettre à jour le msg. Enregistrez et fermez l’éditeur.

Etape 3 : dans les fichiers de validation suivants, mettez à jour le msg de validation à votre guise

Etape 4 : après tous les commits, les msgs sont mis à jour. vous pouvez vouloir faire git push -f pour mettre à jour la télécommande.

Utilisez ces deux étapes dans la console:

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

et alors

 git push -f 

Terminé 🙂

Il convient de noter que si vous utilisez push --force avec des références multiples, elles seront TOUTES modifiées en conséquence. Assurez-vous de faire attention à l’endroit où votre repo git est configuré pour pousser. Heureusement, il existe un moyen de protéger légèrement le processus en spécifiant une seule twig à mettre à jour. Lire depuis les pages de manuel de git:

Notez que –force s’applique à toutes les références qui sont poussées, par conséquent, l’utiliser avec push.default défini sur correspondant ou sur plusieurs destinations push configurées avec remote. *. Push peut remplacer les refs autres que la twig actuelle (y compris les refs locales). ssortingctement derrière leur homologue à distance). Pour forcer une poussée sur une seule twig, utilisez un + devant la refspec pour pousser (par exemple, git push origin + master pour forcer une poussée sur la twig principale).

Si vous voulez modifier un ancien commit, pas le dernier, vous devrez utiliser la commande rebase comme expliqué dans la page d’aide de Github , dans la section Modification du message de l’ancien ou du message de validation multiple

Commande 1 .

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

Alors,

Commande 2 .

 git push origin --force 
 git commit --amend 

puis éditez puis modifiez le message dans la fenêtre en cours. Après cela

 git push --force-with-lease 

Cela fonctionne bien pour moi,

git checkout origine / branchname

si vous êtes déjà en succursale, il est préférable de tirer ou de 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 souhaitez ouvrir l’éditeur de texte, puis utilisez

 git commit --amend 

Je préférerais utiliser l’éditeur de texte si vous avez beaucoup de 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 fini de modifier le message de validation, enregistrez-le et quittez

et puis courir

 git push --force 

Et tu as fini

Une autre option consiste à créer un “commit d’errata” supplémentaire (et pousser) qui référence l’object de validation contenant l’erreur – le nouveau commit d’errata fournit également la correction. Un commit d’errata est un commit sans modifications de code substantielles mais un message de validation important – par exemple, ajoutez un caractère d’espace à votre fichier readme et --allow-empty avec le message de validation important, ou utilisez l’option git --allow-empty . Il est certainement plus facile et plus sûr que le rebasage, il ne modifie pas l’historique, et il garde l’arbre de twig propre (utiliser amend est aussi un bon choix si vous corrigez le dernier commit, mais un commit d’errata peut être un bon choix pour plus vieux commits). Ce genre de chose arrive si rarement que simplement documenter l’erreur est suffisant. À l’avenir, si vous devez rechercher un mot-clé d’entité dans un journal git, la validation d’origine (erronée) risque de ne pas apparaître car le mot-clé incorrect a été utilisé dans la validation d’origine (la faute de frappe d’origine). dans le commit d’errata qui vous dirigera ensuite vers le commit d’origine qui avait la faute de frappe. Voici un exemple:

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

     Errata commettre:
     Ce commit n'a pas de changement de code substantiel.
     Cette validation est uniquement fournie pour documenter une correction apscope à un message de validation précédent.
     Cela concerne la validation de l'object e083a7abd8deb5776cb304fa13731a4182a24be1
     Message de validation incorrect original:
         Changement de la couleur de fond en rouge
     Correction (* changement surligné *):
         Changement de la couleur de fond en * bleu *

 commettre 032d0ff0601bff79bdef3c6f0a02ebfa061c4ad4
 Auteur: First Last 
 Date: mer. Août 8 15:43:16 2018 -0600

     Un message de validation provisoire

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

     Changement de la couleur de fond en rouge