Question Comment annuler un commit de fusion déjà envoyé à une branche distante?


git revert <commit_hash> seul ne fonctionnera pas. -m doit être spécifié, et je suis assez confus à ce sujet.

Quelqu'un a déjà vécu ça?


531
2017-08-17 21:37


origine


Réponses:


le -m option spécifie le numéro de parent. En effet, un commit de fusion a plus d'un parent, et Git ne sait pas automatiquement quel parent était la ligne principale, et quel parent était la branche que vous voulez désassembler.

Lorsque vous affichez un commit de fusion dans la sortie de git log, vous verrez ses parents inscrits sur la ligne qui commence par Merge:

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <ben@example.com>
Date:   Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'

Conflicts:
    README

Dans cette situation, git revert 8f937c6 -m 1 vous obtiendrez l'arbre comme il était dans 8989ee0, et git revert -m 2 rétablira l'arbre tel qu'il était dans 7c6b236.

Pour mieux comprendre les ID parents, vous pouvez exécuter:

git log 8989ee0 

et

git log 7c6b236

639
2017-08-17 21:53



Voici un exemple complet dans l'espoir que cela aide quelqu'un:

git revert -m 1 <commit-hash> 
git commit -m "Reverting the last commit which messed the repo."
git push -u origin master

<commit-hash> est le hash de validation de la fusion que vous souhaitez rétablir, et comme indiqué dans l'explication de cette réponse, -m 1 indique que vous souhaitez revenir à l'arborescence du premier parent avant la fusion.

le git commit ... line valide essentiellement vos modifications tandis que la troisième ligne rend vos modifications publiques en les poussant vers la branche distante.


240
2017-07-04 17:09



Ben vous a dit comment annuler un commit de fusion, mais c'est très important vous vous en rendrez compte "déclare que vous ne voudrez plus jamais les changements d'arbre apportés par la fusion.Par conséquent, les fusions ultérieures n'apporteront que des changements d'arbre introduits par des commits qui ne sont pas des ancêtres de la fusion précédemment restaurée. ne sois pas ce que tu veux. " (page de manuel git-merge).

Un article / mailing list message lié à la page man détaille les mécanismes et les considérations qui sont impliqués. Assurez-vous simplement que vous comprenez que si vous annulez le commit de fusion, vous ne pouvez pas simplement fusionner la branche plus tard et attendre les mêmes changements pour revenir.


114
2017-08-18 01:23



Vous pouvez suivre ces étapes pour rétablir la (les) validation (s) incorrecte (s) ou réinitialiser votre branche distante pour corriger HEAD / state.

  1. checkout la branche distante au repo local.
    git checkout development
  2. Copiez le hash de validation (c'est-à-dire l'identifiant de la validation immédiatement avant la mauvaise validation) depuis le journal git git log -n5

    sortie:

    commit 7cd42475d6f95f5896b6f02e902efab0b70e8038 "Fusionner la branche 'mal-commettre' en 'développement'"
      commettre f9a734f8f44b0b37ccea769b9a2fd774c0f0c012 "ceci est un mauvais commit"
      commettre 3779ab50e72908da92d2cfcd72256d7a09f446ba "ceci est le bon commit"

  3. réinitialiser la branche au commit hash copié à l'étape précédente
    git reset <commit-hash> (i.e. 3779ab50e72908da92d2cfcd72256d7a09f446ba)

  4. lancer le git status pour montrer tous les changements qui faisaient partie du mauvais commit.
  5. simplement courir git reset --hard pour revenir à tous ces changements.
  6. force-pousse votre branche locale à distance et notez que votre historique de commit est propre tel qu'il était avant qu'il ne soit pollué.
    git push -f origin development

45
2018-01-26 13:50



git revert -m 1 <merge-commit>

24
2017-09-27 14:03



Parfois, le moyen le plus efficace de revenir en arrière est de prendre du recul et de remplacer.

git log

Utilisez le hachage 2nd commit (hachage complet, celui que vous souhaitez rétablir, avant l'erreur répertoriée), puis rebranchez-le à partir de là.

git checkout -b newbranch <HASH>

Ensuite, supprimez l'ancienne branche, copiez la nouvelle branche à sa place et recommencez à partir de là.

git branch -D oldbranch
git checkout -b oldbranch newbranch

Si elle a été diffusée, supprimez l'ancienne branche de tous les dépôts, poussez la branche refaite au plus central, et ramenez-la à tous.


13
2018-06-14 18:23



Pour garder le journal propre car rien ne s'est passé (avec quelques inconvénients avec cette approche (en raison de push -f)):

git checkout <branch>
git reset --hard <commit-hash-before-merge>
git push -f origin HEAD:<remote-branch>

'commit-hash-before-merge' vient du journal (git log) après la fusion.


8
2018-05-03 08:43



J'ai trouvé la création d'un correctif inverse entre deux points d'extrémité connus et l'application de ce correctif fonctionnait. Cela suppose que vous avez créé des snapshots (tags) de votre branche master ou même une sauvegarde de votre branche master dites master_bk_01012017.

Dites que la branche de code que vous avez fusionnée dans master était mycodebranch.

  1. Maître de caisse
  2. Créez un correctif binaire complet entre le maître et votre sauvegarde. git diff --binary master..master_bk_01012017 > ~/myrevert.patch
  3. Vérifiez votre patch git apply --check myrevert.patch
  4. Appliquer le correctif avec l'approbation git am --signoff < myrevert.patch
  5. Si vous avez besoin de ramener ce code une fois qu'il a été corrigé, vous devrez déconnecter le maître réversible et extraire la branche fix git branch mycodebranch_fix git checkout mycodebranch_fix
  6. Ici, vous devez trouver la clé SHA pour rétablir et rétablir le retour git revert [SHA]
  7. Maintenant, vous pouvez utiliser votre mycodebranch_fix pour corriger les problèmes, valider et refaire la fusion dans le maître une fois terminé.

1
2018-02-24 15:57