Réponses:
git reset --soft HEAD~1devrait faire ce que vous voulez. Après cela, vous aurez les premières modifications dans l'index (visible avec git diff --cached), et vos dernières modifications ne seront pas mises en scène. git statusressemblera alors à ceci:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo.java
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: foo.java
#
Vous pouvez ensuite effectuer git add foo.javaet valider les deux modifications à la fois.
git commit --amendfait; mais avec un workflow beaucoup plus compliqué. Cela ne répond pas à la question posée par OP, malgré une bonne direction ( git reset).
git reset --soft HEAD~
Utilisation:
git reset HEAD^
Cela fait une réinitialisation "mixte" par défaut, qui fera ce que vous avez demandé; mettez foo.java dans unstaged, supprimant le commit le plus récent.
git reset --softn'a pas fonctionné, mais git reset HEAD^a fonctionné
Pour moi, ce qui suit est une manière plus lisible (donc préférable) de le faire:
git reset HEAD~1
Au lieu de 1, il peut y avoir un certain nombre de validations que vous souhaitez supprimer.
git reset --softest juste pour ça: c'est comme git reset --hard, mais ne touche pas les fichiers.
git resetmsgstr "est comme git reset --hardmais ne touche pas les fichiers.". Non git reset --soft. git reset --softmettra en scène les modifications, vous n'aurez donc pas à les ajouter à la mise en scène au cas où vous voudriez les valider, mais vous devrez les faire git reset(oui, une deuxième fois, et sans le --soft) au cas où vous ne le feriez pas. Cette réponse est donc courte, mais incorrecte.
"Réinitialiser" est le moyen d'annuler les modifications localement. Lors de la validation, vous sélectionnez d'abord les modifications à inclure avec " git add " - c'est ce qu'on appelle "mise en scène". Et une fois les changements mis en scène, vous les " git commit ".
Pour vous retirer de la mise en scène ou de la validation, vous "réinitialisez" la TÊTE. Sur une branche, HEAD est une variable git qui pointe vers le commit le plus récent. Donc, si vous avez mis en scène mais ne vous êtes pas engagé, vous " git reset HEAD ." Cela revient à la tête actuelle en retirant les changements de la scène. C'est un raccourci pour " git reset --mixed HEAD ~ 0 ".
Si vous avez déjà validé, alors le HEAD a déjà avancé, vous devez donc sauvegarder le commit précédent. Ici, vous " réinitialiser HEAD ~ 1 " ou " réinitialiser HEAD ^ 1 " ou " réinitialiser HEAD ~ " ou " réinitialiser HEAD ^ " - toutes les références HEAD moins une.
Quel est le meilleur symbole, ~ ou ^? Considérez le ~ tilde comme un flux unique - lorsque chaque commit a un seul parent et que ce n'est qu'une série de changements dans l'ordre, vous pouvez référencer la sauvegarde du flux à l'aide du tilde, comme HEAD ~ 1, HEAD ~ 2, HEAD ~ 3, pour les parents, les grands-parents, les arrière-grands-parents, etc. (techniquement, il s'agit de trouver le premier parent des générations précédentes).
En cas de fusion, les validations ont plus d'un parent. C'est alors que le ^ caret entre en jeu - vous vous en souvenez car il montre les branches qui se rejoignent. À l'aide du curseur, HEAD ^ 1 serait le premier parent et HEAD ^ 2 serait le deuxième parent d'un seul engagement - mère et père, par exemple.
Donc, si vous revenez en arrière d'un saut sur une validation monoparentale, HEAD ~ et HEAD ^ sont équivalents - vous pouvez utiliser l'un ou l'autre.
De plus, la réinitialisation peut être --soft , --mixed ou --hard . Une réinitialisation logicielle annule simplement la validation - elle réinitialise la HEAD, mais elle ne récupère pas les fichiers de la validation précédente, donc toutes les modifications dans le répertoire de travail sont conservées. Et --soft reset n'efface même pas l'étape (également connue sous le nom d' index ), donc tous les fichiers qui ont été mis en scène seront toujours sur scène.
Une réinitialisation --mixed (par défaut) ne récupère pas non plus les fichiers du commit précédent, donc toutes les modifications sont conservées, mais l'étape est effacée. C'est pourquoi un simple " git reset HEAD " effacera la scène.
Une réinitialisation --hard réinitialise le HEAD, et il efface la scène, mais il extrait également tous les fichiers de la validation précédente et écrase donc toutes les modifications.
Si vous avez poussé la validation vers un référentiel distant, la réinitialisation ne fonctionne pas si bien. Vous pouvez réinitialiser localement, mais lorsque vous essayez de pousser vers la télécommande, git verra que votre HEAD local est derrière le HEAD dans la branche distante et refusera de pousser. Vous pouvez forcer la poussée, mais git n'aime vraiment pas faire ça.
Vous pouvez également stocker vos modifications si vous souhaitez les conserver, consulter le commit précédent, annuler le stockage des modifications, les mettre en scène, créer un nouveau commit, puis pousser cela.
Supposons que vous souhaitiez annuler les modifications jusqu'à ce qu'elles soient validées,
Où les hachages de validation sont les suivants:
Exécutez ensuite la commande suivante:
git reset hn
Maintenant, la TETE sera à hn + 1. Les modifications de h1 à hn ne seront pas mises en scène.