Annuler les changements effectués par fusion

Le développeur a été la validation de petits changements pour les deux fichiers. Mais au cours de cette validation, il avait un conflit de fusion supprimé beaucoup de choses (n'a sans doute pas la dernière version à jour). Ensuite, il a été poussé à la partagé repo et quelques autres développeurs ont fait de certains autres commits.

Maintenant, nous avons remarqué, que la fusion supprimé les fichiers importants, et nous voulons revenir en arrière.

Comment puis-je le faire sans perdre les modifications à partir de la prochaine engage?

J'essayais de git revert commitsha, mais il n'a pas apporté les modifications. Ai-je besoin de revenir la mergesha? Comment puis-je savoir cela?

InformationsquelleAutor Sfisioza | 2011-11-30
  1. 28

    git revert --mainline

    Généralement:

    git revert --mainline 1 dd8cbe3e4

    Où:

    • dd8cbe3e4 est le revers de la fusion de validation que vous souhaitez annuler, et
    • --mainline vous indique laquelle des multiples précédentes s'engage est le seul à restaurer (rappelez-vous, une fusion s'engager a de multiples parent s'engage et vous pouvez ne garder qu'une seule d'entre elles).
      • Je ne peux pas trouver une bonne explication de ce que le 1 moyens, mais ma conjecture est que 1,2,3... correspond à une liste de mappages pour les engage immédiatement avant dd8cbe3e4, triés par croissant ordre chronologique (les plus anciens en premier - ce qui est généralement ce que vous voulez revenir).

    Source:

    http://thezencoder.com/2013/09/05/how-to-correctly-revert-a-bad-merge-in-git/

    InformationsquelleAutor Sridhar Sarnobat
  2. 8

    En bref, AVERTISSEMENT: il n'y a pas de véritable sûr moyen d'annuler une opération de fusion, sauf pour fait réinitialiser la direction générale de la validation avant la fusion.

    Permettez-moi d'expliquer et de parcourir une référence existante pour l'instant.

    Citant liés réponse de Comment voulez-vous revenir à une défaillance de la commande git commit de fusion

    Fondamentalement, le rétablissement d'une opération de fusion permet d'annuler les modifications de données, mais pas l'histoire (graphique) des changements. Par conséquent, il est prévu que le retour de votre défectueux de fusion ne fait rien.

    Certainement, la réinitialisation de la branche serait le plus simple, mais elle a des inconvénients si le résultat de la fusion a déjà été poussé à une salle de repo (parce que vous êtes effectivement réécriture publié l'histoire).

    Voici la ventilation

    • git merge <someref> de fusion (en option s'engager après la résolution des conflits)

    • Si vous découvrez tout de suite que vous souhaitez réinitialiser la branche d'avant la fusion:

      git reset HEAD@{1} 
     # optionally pass --hard to reset the working tree too

    • si vous avez découvert que sur le tard,

      • par le reflog pour trouver le point avant la fusion. (HEAD@{1} est court pour la valeur précédente de l'actuel chef de référence, mais le reflog pistes un historique limité de valeurs pour la tête de référence)

        git reflog

      • réinitialiser la branche

        git reset HEAD@{n} # substitute reflog entry index

      • éventuellement rebase/cherry-pick les commits effectués après la fusion

        git cherry-pick HEAD@{1} # just an example. interactive tools will make this easier
    • Grâce sehe ce fut assez proche! Bien sûr, il ne fonctionne pas en raison de certaines autres erreurs. J'espère, un jour, une équipe va créer un système de contrôle de version qui n'a pas besoin d'un diplôme de master et les développeurs peuvent se concentrer sur le développement plutôt que de passer des jours à essayer de comprendre un système qui est fait sûr, mais aussi déroutant que cela peut être. Je n'aime pas git depuis le premier jour que je l'utilise et qui n'a pas changé depuis, il évolue cependant, va être bon un jour 🙁
    • Le problème avec reset plutôt que d'en revenir, c'est que si vous avez déjà poussé la mauvaise fusion et d'autres ont réussi, ça va compliquer la vie pour eux. Une fois que vous poussez, vous devez créer compensatoires nouvelle s'engage plutôt que de retirer engage.
    • C'est la même question que jamais avec l'évolution de la publié l'histoire. Ce n'est pas un problème avec le reset, c'est un problème à la publication de l'histoire 🙂
    • Droit, mais que voulez-vous faire une fois que vous avez réinitialisé à la dernière bonne engager? C'est analogue à la synchronisation des horloges dans les systèmes distribués. Vous ne devriez jamais revenir en arrière dans le temps.
    • Il n'y a pas de place pour "mais" dans votre dernier message: c'est juste de la réaffirmation de ce que vous avez déjà dit. Ce même point a été dans ma réponse depuis 30 Nov '11. Je suppose que vous pouvez utiliser cette réponse comme une raison de (a) éviter de fusion, de favoriser la pull --rebase (b) ne jamais modifier les conflits de fusion la fusion commit (c) ne pas bork fusionne (d) permettre git-rerere
    • Oui, vous avez raison, je n'ai pas lu intégralement votre réponse originale à cette question (et d'autres à voir, il peut pas non plus).

    InformationsquelleAutor sehe
  3. 6

    L'autre (plus safe) approche consiste à créer une diff entre le dernier bon et la version actuelle du fichier, puis de restaurer les pièces perdues par copie&coller.

    Cela fonctionne toujours, n'a pas besoin de tout bizarre options de ligne de commande, et il n'a pas de sabotage avec des choses que vous devriez laisser seul 🙂

    Eclipse, par exemple, a de bons outils à la cerise choisir chaque différence et de la copie de chaque version. Suffit d'utiliser la fonction "Comparer" menu pour ouvrir les deux versions côte à côte.

    • Malheureusement, vous avez raison. À titre de mesure préventive, il est préférable de rebase plutôt de fusion
    InformationsquelleAutor Aaron Digulla
  4. 0

    En bref, vous pouvez faire un git reset --soft <commit>
    où commit peut être HEAD^ (précédent), HEAD~2 (courant-2), SHA, etc.

    Avec --soft tous les changements seront prêt à s'engager, de sorte que vous pouvez réellement changer la commettre. Avec --dur les changements seront tous perdus.

    Après que vous avez modifié le commit que vous avez à force de pousser les modifications à la partagé repo avec git push --force.

    Notez que vous aurez besoin de dire à l'autre que les développeurs devraient rebase leur repos sur l'partagé des pensions. (utiliser git pull --rebase). Ils pourraient obtenir certains conflits de fusion si... s'il vous Plaît garder cela à l'esprit.

    InformationsquelleAutor Hiery Nomus