Comment puis-je convertir un référentiel Git en un commit précédent?
Comment puis-je revenir de mon état actuel à un instantané créé sur un certain commit?
Si je fais git log, alors je reçois la sortie suivante:
$ git log
commit a867b4af366350be2e7c21b8de9cc6504678a61b`
Author: Me <[email protected]>
Date: Thu Nov 4 18:59:41 2010 -0400
blah blah blah...
commit 25eee4caef46ae64aa08e8ab3f988bc917ee1ce4
Author: Me <[email protected]>
Date: Thu Nov 4 05:13:39 2010 -0400
more blah blah blah...
commit 0766c053c0ea2035e90f504928f8df3c9363b8bd
Author: Me <[email protected]>
Date: Thu Nov 4 00:55:06 2010 -0400
And yet more blah blah...
commit 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
Author: Me <[email protected]>
Date: Wed Nov 3 23:56:08 2010 -0400
Yep, more blah blah.
Comment revenir au commit à partir du 3 novembre, c’est-à-dire commit 0d1d7fc?
Cela dépend beaucoup de ce que vous entendez par "revenir".
Passer temporairement à un commit différent
Si vous voulez y retourner temporairement, batifoler, puis revenir à votre position actuelle, il vous suffit de vérifier le commit voulu:
# This will detach your HEAD, that is, leave you with no branch checked out:
git checkout 0d1d7fc32
Ou si vous voulez vous engager pendant que vous y êtes, allez-y et créez une nouvelle branche pendant que vous y êtes:
git checkout -b old-state 0d1d7fc32
Pour revenir à l'endroit où vous étiez, vérifiez simplement la branche dans laquelle vous vous trouviez. (Si vous avez apporté des modifications, comme toujours lorsque vous changez de branche, vous devrez les gérer comme il convient. Vous pouvez réinitialiser pour les jeter. Vous pouvez stocker, sortir, cacher des pop pour les emporter; vous pouvez commettre si vous voulez une succursale là-bas)
Supprimer durement les commits non publiés
Si, par contre, vous voulez vraiment vous débarrasser de tout ce que vous avez fait depuis lors, il existe deux possibilités. Premièrement, si vous n'avez publié aucune de ces commits, réinitialisez simplement:
# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32
# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to.
Si vous vous trompez, vous avez déjà rejeté vos modifications locales, mais vous pouvez au moins retrouver votre état antérieur en réinitialisant à nouveau.
Annuler les commits publiés avec les nouveaux commits
D'un autre côté, si vous avez publié le travail, vous ne voudrez probablement pas réinitialiser la branche, car il s'agit bien de réécrire l'historique. Dans ce cas, vous pouvez en effet annuler les commits. Avec Git, revert a une signification très spécifique: créez un commit avec le patch inverse pour l'annuler. De cette façon, vous ne réécrivez aucune histoire.
# This will create three separate revert commits:
git revert a867b4af 25eee4ca 0766c053
# It also takes ranges. This will revert the last two commits:
git revert HEAD~2..HEAD
#Similarly, you can revert a range of commits using commit hashes:
git revert a867b4af..0766c053
# Reverting a merge commit
git revert -m 1 <merge_commit_sha>
# To get just one, you could use `rebase -i` to squash them afterwards
# Or, you could do it manually (be sure to do this at top level of the repo)
# get your index and work tree into the desired state, without changing HEAD:
git checkout 0d1d7fc32 .
# Then commit. Be sure and write a good message describing what you just did
git commit
La git-revert manpage couvre en fait beaucoup de choses dans sa description. Un autre lien utile est cette section de git-scm.com traitant de git-revert .
Si vous décidez que vous ne voulez pas revenir après tout, vous pouvez annuler le retour (comme décrit ici) ou le rétablir avant le retour (voir la section précédente).
Vous pouvez également trouver cette réponse utile dans ce cas:
Comment déplacer HEAD vers un emplacement précédent? (Tête détachée)
Rogue Coder?
Travailler seul et vous voulez que ça marche? Suivez les instructions ci-dessous, ils travaillent de manière fiable pour moi et beaucoup d’autres depuis des années.
Travailler avec d'autres? Git est compliqué. Lisez les commentaires ci-dessous cette réponse avant de faire quelque chose d'éruption cutanée.
Rétablir la copie de travail à la plus récente validation
Pour revenir à un commit précédent, en ignorant les modifications:
git reset --hard HEAD
où HEAD est la dernière validation de votre branche actuelle
Rétablir la copie de travail sur une ancienne publication
Pour revenir à un commit plus ancien que le plus récent:
# Resets index to former commit; replace '56e05fced' with your commit code
git reset 56e05fced
# Moves pointer back to previous HEAD
git reset --soft HEAD@{1}
git commit -m "Revert to 56e05fced"
# Updates working copy to reflect the new commit
git reset --hard
Les crédits vont à une question de débordement de pile similaire, Revenir à une validation par un hachage SHA dans Git?.
Beaucoup de réponses compliquées et dangereuses ici, mais c'est en fait facile:
git revert --no-commit 0766c053..HEAD
git commit
Ceci retournera tout du HEAD au hash de commit, ce qui signifie qu'il recréera cet état de commit dans l'arbre de travail comme si chaque commit depuis avait été repris. Vous pouvez ensuite valider l’arborescence en cours et créer une nouvelle validation essentiellement équivalente à celle que vous avez "rétablie".
(L’option --no-commit permet à git d’annuler tous les commits en une fois. Sinon, un message vous sera demandé pour chaque commit de la plage, incrustant votre historique de nouveaux commits inutiles.)
Ceci est un moyen sûr et facile de revenir à un état antérieur. Aucune histoire n'est détruite, elle peut donc être utilisée pour des commits déjà rendus publics.
La meilleure option pour moi et probablement d'autres est l'option de réinitialisation Git:
git reset --hard <commidId> && git clean -f
Cela a été la meilleure option pour moi! C'est simple, rapide et efficace!
Remarque: Comme mentionné dans les commentaires, ne le faites pas si vous partagez votre branche avec d'autres personnes possédant des copies des anciens commits
D'après les commentaires également, si vous vouliez une méthode moins "ballzy", vous pouvez utiliser
git clean -i
Avant de répondre, ajoutons un peu de contexte et expliquons en quoi consiste HEADname__.
First of all what is HEAD?
HEADest simplement une référence à la validation actuelle (la plus récente) de la branche actuelle. Il ne peut y avoir qu'un seul HEADà un moment donné (à l'exception de git worktree).
Le contenu de HEADest stocké dans .git/HEAD et contient les 40 octets SHA-1 de la validation actuelle.
detached HEAD
Si vous n’êtes pas sur la dernière validation - ce qui signifie que HEADpointe vers une validation antérieure de l’historique, elle est appelée detached HEAD.
Sur la ligne de commande, cela ressemblera à ceci - SHA-1 au lieu du nom de la branche puisque le HEADne pointe pas vers le sommet de la branche actuelle:
Quelques options sur la façon de récupérer d'une tête isolée:
git checkout
git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back
Cela va vérifier la nouvelle branche pointant vers le commit désiré. Cette commande passera à un commit donné.
À ce stade, vous pouvez créer une branche et commencer à travailler à partir de ce point:
# Checkout a given commit.
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>
# Create a new branch forked to the given commit
git checkout -b <branch name>
git reflog
Vous pouvez toujours utiliser le reflogname__. git reflog affichera toute modification mettant à jour le HEADet extraire l'entrée de reflog désirée remettra le HEADà cette validation.
Chaque fois que le HEAD sera modifié, il y aura une nouvelle entrée dans le reflogname __
git reflog
git checkout HEAD@{...}
Cela vous ramènera à votre commit désiré
git reset HEAD --hard <commit_id>
"Déplacez" votre tête vers le commit souhaité.
# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32
# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to.
- Remarque: ( Depuis Git 2.7 ), vous pouvez également utiliser le
git rebase --no-autostash.
Ce schéma illustre quelle commande fait quoi. Comme vous pouvez le voir, reset && checkout modifiez le HEADname__.
Si vous souhaitez "annuler l'engagement", effacer le dernier message de validation et replacer les fichiers modifiés dans le stockage intermédiaire, utilisez la commande suivante:
git reset --soft HEAD~1
--softindique que les fichiers non validés doivent être conservés en tant que fichiers de travail, contrairement à--hardqui les ignorerait.HEAD~1est le dernier commit. Si vous voulez annuler 3 commits, vous pouvez utiliserHEAD~3. Si vous souhaitez revenir à un numéro de révision spécifique, vous pouvez également le faire en utilisant son hash SHA.
C'est une commande extrêmement utile dans les situations où vous avez commis une erreur et que vous souhaitez annuler le dernier commit.
Source: http://nakkaya.com/2009/09/24/git-delete-last-commit/
J'ai essayé de nombreuses manières de restaurer les modifications locales dans Git, et il semble que cela fonctionne le mieux si vous souhaitez simplement revenir au dernier état de validation.
git add . && git checkout master -f
Brève description:
- Il ne créera PAS de commits comme le fait
git revert. - Il ne détachera PAS votre HEAD comme le fait
git checkout <commithashcode>. - Il va annuler toutes vos modifications locales et supprimer tous les fichiers ajoutés depuis la dernière validation dans la branche.
- Cela fonctionne uniquement avec les noms de branches, vous pouvez donc revenir uniquement à la dernière validation dans la branche.
J'ai trouvé un moyen beaucoup plus pratique et simple d'obtenir les résultats ci-dessus:
git add . && git reset --hard HEAD
où HEAD pointe vers la dernière validation de votre branche actuelle.
C’est le même code que celui suggéré par boulder_Ruby, mais j’ai ajouté git add . avant git reset --hard HEAD pour effacer tous les nouveaux fichiers créés depuis le dernier commit, car c’est ce à quoi la plupart des gens s’attendent lors du retour au dernier commit.
Vous pouvez le faire avec les deux commandes suivantes:
git reset --hard [previous Commit SHA id here]
git Push Origin [branch Name] -f
Cela supprimera votre précédent commit Git.
Si vous souhaitez conserver vos modifications, vous pouvez également utiliser:
git reset --soft [previous Commit SHA id here]
Ensuite, vos modifications seront sauvegardées.
OK, il est assez facile de revenir au commit précédent dans git ...
Revenir en arrière sans conserver les modifications:
git reset --hard <commit>
Revenir en arrière en conservant les modifications:
git reset --soft <commit>
Expliquez: en utilisant la réinitialisation de git, vous pouvez restaurer un état spécifique. Il est courant de l'utiliser avec un hachage de validation comme vous le voyez ci-dessus.
Mais comme vous le voyez, la différence consiste à utiliser les deux indicateurs --soft et --hard, par défaut git reset à l'aide de --soft indicateur, mais il est judicieux de toujours utiliser l'indicateur, j'explique chaque indicateur:
--doux
L’indicateur par défaut, tel qu’expliqué, ne nécessite pas de le fournir, ne modifie pas l’arborescence de travail, mais ajoute tous les fichiers de modifications prêts à être validés. Vous revenez donc au statut de validation des modifications apportées aux fichiers sans décomposition.
--difficile
Soyez prudent avec cet indicateur, il réinitialise l'arborescence de travail et toutes les modifications apportées aux fichiers suivis et tout sera parti!
J'ai également créé l'image ci-dessous qui peut se produire dans une vraie vie travaillant avec git:
Rien ici ne fonctionnait pour moi en dehors de cette combinaison exacte:
git reset --hard <commit_hash>
git Push Origin <branch_name> --force
La clé ici est de forcer le Push, pas de commits/commits de commit supplémentaires, etc.
Supposons que vous ayez les commits suivants dans un fichier texte nommé ~/commits-to-revert.txt (j’ai utilisé git log --pretty=oneline pour les obtenir)
fe60adeba6436ed8f4cc5f5c0b20df7ac9d93219
0c27ecfdab3cbb08a448659aa61764ad80533a1b
f85007f35a23a7f29fa14b3b47c8b2ef3803d542
e9ec660ba9c06317888f901e3a5ad833d4963283
6a80768d44ccc2107ce410c4e28c7147b382cd8f
9cf6c21f5adfac3732c76c1194bbe6a330fb83e3
fff2336bf8690fbfb2b4890a96549dc58bf548a5
1f7082f3f52880cb49bc37c40531fc478823b4f5
e9b317d36a9d1db88bd34831a32de327244df36a
f6ea0e7208cf22fba17952fb162a01afb26de806
137a681351037a2204f088a8d8f0db6e1f9179ca
Créez un script Bash pour restaurer chacun d'eux:
#!/bin/bash
cd /path/to/working/copy
for i in `cat ~/commits-to-revert.txt`
do
git revert $i --no-commit
done
Cela ramène tout à l’état précédent, y compris les créations de fichiers et de répertoires, et les suppressions, le commet dans votre branche et vous conservez l’historique, mais vous le rétablissez dans la même structure de fichiers. Pourquoi Git n'a pas de git revert --to <hash> me dépasse.
En supposant que vous parlez de maître et de cette branche respective (cela dit, cela pourrait être n'importe quelle branche en activité qui vous concerne):
# Reset local master branch to November 3rd commit ID
git reset --hard 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
# Reset remote master branch to November 3rd commit ID
git Push -f Origin 0d1d7fc32e5a947fbd92ee598033d85bfc445a50:master
J'ai trouvé la réponse dans un article de blog (n'existe plus maintenant)
Notez qu’il s’agit de Réinitialiser et de forcer la modification sur la télécommande, de sorte que si d’autres membres de votre équipe ont déjà tiré, vous leur causerez des problèmes. Vous détruisez l'historique des changements, ce qui est une raison importante pour laquelle les gens utilisent git en premier lieu.
Il est préférable d’utiliser Revert (voir autres réponses) plutôt que de réinitialiser. Si vous êtes une équipe composée d'un seul homme, peu importe.
Alternatives supplémentaires aux solutions de Jefromi
Les solutions de Jefromi sont certainement les meilleurs et vous devriez les utiliser. Cependant, par souci d'exhaustivité, je souhaitais également montrer ces autres solutions alternatives pouvant également être utilisées pour annuler un commit (dans le sens où vous créez un nouveau commit qui annule les modifications apportées précédemment. commit , comme ce que fait git revert).
Pour être clair, ces alternatives ne sont pas le meilleur moyen de revenir en arrière commits , Jefromi's solutions sont , mais je tiens simplement à souligner que vous pouvez également utiliser ces méthodes pour obtenir la même chose que git revert.
Alternative 1: réinitialisations matérielles et logicielles
Ceci est une version très légèrement modifiée de la solution de Charles Bailey à Revenir à un commit par un hash SHA dans Git? :
# Reset the index to the desired commit
git reset --hard <commit>
# Move the branch pointer back to the previous HEAD
git reset --soft HEAD@{1}
# Commit the changes
git commit -m "Revert to <commit>"
Cela fonctionne essentiellement en utilisant le fait que les réinitialisations logicielles laisseront l'état du commit précédent mis en scène dans la zone d'index/staging, que vous pouvez ensuite valider.
Alternative 2: Supprimer l'arborescence actuelle et la remplacer par la nouvelle
Cette solution provient de la solution de svick vers Checkout old commit et en fait un nouveau commit :
git rm -r .
git checkout <commit> .
git commit
Comme pour la variante n ° 1, ceci reproduit l’état de <commit> dans la copie de travail en cours. Il est nécessaire de commencer par git rm car git checkout ne supprimera pas les fichiers ajoutés depuis <commit>.
Voici un moyen beaucoup plus simple de revenir à un commit précédent (et de l'avoir dans un état non-accepté, d'en faire ce que vous voudrez):
git reset HEAD~1
Donc, pas besoin d'identifiants de commit, etc. :)
Après toutes les modifications, lorsque vous appuyez sur toutes ces commandes, vous devrez peut-être utiliser:
git Push -f ...
Et pas seulement git Push.
Il y a une commande (qui ne fait pas partie du noyau Git, mais elle est dans le paquet git-extras ) spécifiquement pour annuler et mettre en place les anciens commits:
git back
Selon le page de manuel , il peut également être utilisé comme tel:
# Remove the latest three commits
git back 3
Vous pouvez effectuer vous-même toutes ces étapes initiales et repousser vers git repo.
Extrayez la dernière version de votre référentiel à partir de Bitbucket à l'aide de la commande
git pull --all.Exécutez la commande git log avec -n 4 à partir de votre terminal. Le nombre après le -n détermine le nombre de validations dans le journal à partir de la validation la plus récente de votre historique local.
$ git log -n 4Réinitialisez la tête de l'historique de votre référentiel à l'aide de
git reset --hard HEAD~N, où N est le nombre de commits que vous souhaitez récupérer. Dans l'exemple suivant, l'en-tête serait initialisé d'une sauvegarde, à la dernière validation de l'historique du référentiel:Appuyez sur le changement dans git repo en utilisant
git Push --forcepour forcer le changement.
Si vous voulez que le dépôt git soit un commit précédent
git pull --all
git reset --hard HEAD~1
git Push --force
Revenir à le plus récent commettre en ignorant tous les changements locaux:
git reset --hard HEAD
Sélectionnez votre commit requis et vérifiez-le par
git show HEAD
git show HEAD~1
git show HEAD~2
jusqu'à ce que vous obteniez le commit requis. Pour que le HEAD pointe sur cela, faites
git reset --hard HEAD~1
ou git reset --hard HEAD~2 ou autre chose.
C’est un autre moyen de réinitialiser directement un commit récent.
git stash
git stash clear
Il efface directement toutes les modifications que vous avez effectuées depuis le dernier commit.
PS: Cela pose un petit problème. il supprime également toutes les modifications de stockage que vous avez récemment stockées. Ce qui, je suppose, dans la plupart des cas ne devrait pas avoir d'importance.
Pour conserver les modifications du commit précédent dans HEAD et passer au commit précédent, procédez comme suit:
git reset <SHA>
Si des modifications ne sont pas requises de la précédente validation sur HEAD et que vous ne supprimez que toutes les modifications, procédez comme suit:
git reset --hard <SHA>
Pour nettoyer complètement le répertoire d'un codeur de quelques modifications accidentelles, nous avons utilisé:
git add -A .
git reset --hard HEAD
Juste git reset --hard HEAD va se débarrasser des modifications, mais il ne se débarrassera pas des "nouveaux" fichiers. Dans leur cas, ils avaient accidentellement fait glisser un dossier important quelque part au hasard, et tous ces fichiers étaient traités comme nouveaux par Git, de sorte qu'un reset --hard ne le répare pas. En exécutant le git add -A . au préalable, il les a tous explicitement suivis avec git, pour être effacés par la réinitialisation.
Je pense que certaines personnes voudront peut-être savoir comment annuler les modifications engagées dans leur maître - c'est-à-dire tout jeter et revenir à l'origine/maître, auquel cas, procédez comme suit:
git reset --hard Origin/master
https://superuser.com/questions/273172/how-to-reset-master-to-Origin-master
Revert est la commande pour annuler les commits.
git revert <commit1> <commit2>
échantillon:
git revert 2h3h23233
Il est capable de prendre une plage allant du HEAD comme ci-dessous. Ici, 1 dit "annuler le dernier commit".
git revert HEAD~1..HEAD
et ensuite git Push
Annuler le plus récent engagement:
git reset --hard HEAD
HEADest simplement une référence à la validation actuelle (la plus récente) de la branche actuelle. Il ne peut y avoir qu'un seul HEADà un moment donné.
Revenir à une ancienne publication: Le moyen le plus rapide de restaurer une ancienne version consiste à utiliser la commande resetname__:
# Resets index to former commit
git reset 56e05fced
# Moves pointer back to previous HEAD
git reset --soft HEAD@{1}
# Updates working copy to reflect the new commit
git reset --hard
Cela ramènera votre branche HEAD à la version spécifiée. Tous les commits postérieurs à cette version sont effectivement annulés. votre projet est exactement comme il était à ce moment-là.
La commande de réinitialisation est livrée avec deux options, l’une des plus intéressantes étant l’indicateur --soft. Si vous l'utilisez au lieu de --hard, Git conservera toutes les modifications dans les validations "annulées" en tant que modifications locales.
Restauration d'une révision dans une nouvelle succursale locale
Comme indiqué précédemment, l’utilisation de la commande de réinitialisation sur votre branche HEADest une action assez radicale: elle supprimera les validations (sur cette branche) postérieures à la révision spécifiée. Si vous êtes sûr que c'est ce que vous voulez, tout va bien.
Cependant, il existe également un moyen plus sûr au cas où vous préféreriez laisser votre branche actuelle HEAD intacte. Puisque les "branches" sont si faciles et peu coûteuses dans Git, nous pouvons facilement créer une nouvelle branche qui commence à cette ancienne révision:
git checkout -b old-project-state 0ad5a7a6
Normalement, la commande checkout est utilisée pour simplement changer de branche. Cependant, en fournissant le paramètre -b, vous pouvez également lui permettre de créer une nouvelle branche (nommée old-project-state dans cet exemple). Si vous ne voulez pas qu'il commence à la révision HEAD actuelle, vous devez également fournir un hachage de validation, l'ancienne révision du projet que nous souhaitons restaurer.
Vous avez maintenant une nouvelle branche nommée old-project-state reflétant l'ancienne version de votre projet - sans toucher ni même supprimer d'autres commits ou branches.
Si la situation est urgente , vous voulez simplement faire ce que le demandeur a demandé dans un rapide et sale. , en supposant que votre projet se trouve dans le répertoire "mon projet":
Copiez tout le répertoire et appelez-le autrement, par exemple "mon projet - copier"
Faire:
git reset --hard [first-4-letters&numbers-of-commit's-SHA]
Vous avez alors deux versions sur votre système ... vous pouvez examiner, copier ou modifier les fichiers d’intérêt, ou autre, de la précédente validation. Vous pouvez complètement supprimer les fichiers sous "mon projet - copie", si vous avez décidé que le nouveau travail n'allait nulle part ...
La chose évidente si vous voulez continuer avec l’état du projet sans abandonner le travail puisque ce commit récupéré est de renommer votre répertoire: Supprimez le projet contenant le commit récupéré (ou donnez-lui un nom temporaire) et renommez votre mon projet - copie "répertoire dans" mon projet ". Ensuite, faites probablement un autre commit assez rapidement.
Git est une création brillante, mais vous ne pouvez pas simplement "le ramasser à la volée": les personnes qui essaient de l'expliquer beaucoup trop souvent supposent auparavant connaissance des autres [systèmes de contrôle de version] VCS et approfondir beaucoup trop tôt et commettre d’autres crimes, comme utiliser des termes interchangeables pour "vérifier" - d’une manière qui semble parfois presque risquer de confondre un débutant.
Pour vous épargner beaucoup de stress, vous devez lire un livre sur Git - Je le recommanderais "Contrôle de version avec Git" . Et si vous pouvez vous fier à moi (ou plutôt à mes cicatrices) lorsque je dis "devoir", il en découle que vous pourriez aussi bien le faire MAINTENANT. Une grande partie de la complexité de Git provient de la création de branches, puis de la fusion. Mais d'après votre question, il n'y a aucune raison pour que les gens vous aveuglent avec la science .
Surtout si, par exemple, c'est une situation désespérée et que vous êtes un débutant avec Git!
PS: Une autre pensée: Il est (maintenant) assez simple de conserver le référentiel Git ("repo") dans un répertoire autre que celui contenant les fichiers de travail. Cela signifierait que vous n'auriez pas à copier tout le référentiel Git à l'aide de la solution rapide et sale ci-dessus. Voir la réponse de Fryer en utilisant --separate-git-dir here . Soyez averti , cependant: Si vous avez un référentiel "répertoire séparé" que vous ne copiez pas et que vous effectuez une réinitialisation matérielle, toutes les versions ultérieures La réinitialisation de la validation sera perdue pour toujours, sauf si vous avez, comme vous devez absolument, régulièrement sauvegardé votre référentiel, de préférence sur le cloud (par exemple, Google Drive ), entre autres.
Essayez de réinitialiser le commit désiré -
git reset <COMMIT_ID>
(pour vérifier COMMIT_ID, utilisez git log)
Cela réinitialisera tous les fichiers modifiés à l'état non ajouté.
Maintenant, vous pouvez checkout tous les fichiers non ajoutés en
git checkout .
Vérifiez git log pour vérifier vos modifications.
UPDATE
Si vous avez n seul commettez dans votre rapport, essayez
git update-ref -d HEAD
Attention! Cette commande peut entraîner la perte de l'historique des validations si l'utilisateur commet une erreur par erreur. Ayez toujours une sauvegarde supplémentaire de votre git ailleurs qu'au cas où vous feriez des erreurs, vous serez un peu plus en sécurité. :)
J'ai eu le même problème et je voulais revenir à la version précédente de Commit. Dans mon cas, je n'étais pas intetessered pour garder le plus récent commit donc j'ai utilisé Hard.
Voici comment je l'ai fait:
git reset --hard CommitId && git clean -f
Cela reviendra sur le référentiel local. Après avoir utilisé git Push -f, le référentiel distant sera mis à jour.
git Push -f
Comme vos commits sont poussés à distance, vous devez les supprimer. Laissez-moi supposer que votre branche est en développement et qu’elle est poussée au-dessus de Origin.
Vous devez d'abord supprimer développer d'origine:
git Push Origin :develop (note the colon)
Ensuite, vous devez obtenir le statut souhaité, laissez-moi supposer que le hachage de validation est EFGHIJK:
git reset --hard EFGHIJK
Enfin, Push développe à nouveau:
git Push Origin develop
Sur GitKraken, vous pouvez faire ceci:
- Faites un clic droit sur le commit que vous voulez réinitialiser, choisissez: Réinitialiser à ce commit/Hard :
- Cliquez à nouveau avec le bouton droit sur la validation, choisissez: Nom de la branche actuelle/Push :
- Cliquez sur Forcer Push :
Obs. : Vous devez faire attention car tout l'historique de validation après la réinitialisation matérielle est perdu et cette action est irréversible. Vous devez être sûr de ce que vous faites.
Si vous voulez corriger une erreur dans le dernier commit, une bonne alternative serait d'utiliser la commande git commit --amend. Si le dernier commit n'est pointé par aucune référence, cela fera l'affaire car il créera un commit avec le même parent que le dernier commit. S'il n'y a pas de référence à la dernière validation, celle-ci sera simplement supprimée et cette validation sera la dernière. C'est un bon moyen de corriger les commits sans les annuler. Cependant, il a ses propres limites.
Tout d’abord, obtenez la chaîne qui identifie le commit à une date donnée, en faisant:
git rev-list -n 1 --before="2009-07-27 13:37" Origin/master
il affiche l'identifiant de validation, prend la chaîne (par exemple XXXX) et fait:
git checkout XXXX
Pour le retour en arrière (ou pour revenir en arrière):
- git revert --no-commit "code-à-supprimer" HEAD (par exemple, git revert --no-commit d57a39d HEAD)
- git commit
- git Push
Essayez ci-dessus deux étapes, et si vous trouvez que c'est ce que vous voulez, alors git Push.
Si vous trouvez quelque chose qui ne va pas, faites:
git revert --aide
Cela peut être fait beaucoup plus facilement avec SourceTree . Faites un clic droit sur commit que vous recherchez et choisissez "Checkout" dans le menu.
Encore une autre solution la plus simple. Pour ce faire, vous devez changer de branche, mais vous pouvez ensuite exécuter:
git branch -f <<branchname>> 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
Je ne pouvais pas inverser le mien manuellement pour une raison quelconque, alors voici comment j'ai fini par le faire.
- J'ai vérifié la branche que je voulais avoir, je l'ai copiée.
- Vérifié la dernière branche.
- Copié le contenu de la branche que je voulais dans le répertoire de la dernière branche en écrasant les modifications et en les validant.
git reflog
Choisissez le nombre de tête (s) de git reflog, où vous voulez revenir et faites (pour cet exemple je choisis le 12):
git reset HEAD@{12} --hard
La façon la moins compliquée de rétablir une branche dans un commit particulier pour lequel vous ne pouvez pas modifier l'historique que j'ai trouvé est la suivante:
- vérifiez la validation ou la branche à partir de laquelle vous souhaitez revenir.
- Éditez .git/HEAD et changez la référence en branche vers laquelle vous souhaitez revenir.
Tel que:
echo 'ref: refs/heads/example' > .git/HEAD
Si vous faites ensuite le statut git, vous devriez voir tous les changements entre la branche sur laquelle vous êtes et celle à laquelle vous souhaitez revenir.
Si tout va bien, vous pouvez vous engager. Vous pouvez également utiliser git diff revert..example pour vous assurer qu'il en va de même.
Si vous voulez annuler temporairement les modifications parce que
- quelqu'un a commis du code que sa rupture de la construction ou de la fonctionnalité sur laquelle vous travaillez
Vous pouvez rechercher le dernier commit actif en utilisant git log puis en exécutant
git rebase --onto <commitId>
Lorsque la branche distante fonctionne à nouveau, vous pouvez
git pull --rebase
Cette méthode est meilleure que git checkout pour les modifications temporaires, car vous n'êtes pas détaché.
Réinitialisation des modifications et validations planifiées
La commande git reset vous permet de modifier le HEAD - le dernier commit à valider vos points de travail sur votre référentiel. Il modifie la zone intermédiaire ou la zone intermédiaire et l'arborescence de travail. La capacité de Git à créer des commits exactement comme vous le souhaitez signifie que vous devez parfois annuler les modifications apportées aux modifications que vous avez effectuées avec git add. Vous pouvez le faire en appelant git reset HEAD <file to change>. Vous avez deux options pour vous débarrasser complètement des changements. git checkout HEAD <file(s) or path(s)> est un moyen rapide d'annuler les modifications apportées à votre zone de travail intermédiaire et à votre arbre de travail. Soyez prudent avec cette commande, cependant, car elle supprime toutes les modifications de votre arbre de travail. Git ne sait rien de ces changements car ils n'ont jamais été engagés. Il n'y a aucun moyen de récupérer ces modifications une fois que vous avez exécuté cette commande. Une autre commande à votre disposition est git reset --hard. Il est également dommageable pour votre arbre de travail: toute modification non validée ou mise en échec est perdue après son exécution. Lancer git reset -hard HEAD fait la même chose que git checkout HEAD. cela ne nécessite aucun fichier ni chemin d'accès. Vous pouvez utiliser --soft avec git reset. Il réinitialise le référentiel sur le commit que vous spécifiez et met en œuvre toutes ces modifications. Les modifications que vous avez déjà programmées ne sont pas affectées, pas plus que les modifications dans votre arborescence de travail. Enfin, vous pouvez utiliser --mixed pour réinitialiser l'arborescence de travail sans effectuer de modifications. Ces modifications annulent également les modifications effectuées.
Annulation des validations
Parfois, nous faisons des erreurs. Un commit qui n'était pas supposé être partagé est poussé vers un référentiel public, un commit a un bogue qui ne peut pas être corrigé et qui doit être annulé. Sinon, vous n'avez peut-être plus besoin de ce code.Ces cas tous appelez git revert. La commande git revert fait exactement ce à quoi vous pouvez vous attendre. Il annule une validation en appliquant une validation inverse à l'historique. Parfois, vous devez annuler plusieurs validations pour annuler complètement une modification. Vous pouvez utiliser -no-commit ou -n pour indiquer à Git d'effectuer la restauration mais de ne pas valider la modification. Cela vous permet de combiner tous les commits inversés en un seul, ce qui est utile si vous devez restaurer une fonctionnalité s'étendant sur plusieurs validations. Assurez-vous que vous annulez les commits dans l'ordre inverse, le plus récent en premier. Sinon, vous pourriez confondre Git en essayant de rétablir un code qui n'existe pas encore.