Je cherche à diviser un commit et je ne sais pas quelle option de réinitialisation utiliser.
Je regardais la page En clair, que fait "git reset"? , mais j'ai réalisé que je ne comprenais pas vraiment ce qu'est l'index git ou la zone de transit et donc les explications n'ont pas aidé.
En outre, les cas d'utilisation --mixed
et --soft
la même chose me semblent dans cette réponse (lorsque vous souhaitez corriger et recommencer). Quelqu'un peut-il le décomposer encore plus? Je me rends compte que --mixed
c'est probablement l'option, mais je veux savoir pourquoi . Enfin, qu'en est-il --hard
?
Quelqu'un peut-il me donner un exemple de flux de travail de la façon dont la sélection des 3 options se produirait?
git
version-control
Michael Chinen
la source
la source
soft: stage everything
,mixed: unstage everything
,hard: ignore everything
jusqu'à la commettras je réinitialisation de.David Zych
avec une explication claire - davidzych.com/difference-between-git-reset-soft-mixed-and-hardRéponses:
Lorsque vous modifiez un fichier dans votre référentiel, la modification est initialement non mise en scène. Pour le valider, vous devez le mettre en scène, c'est-à-dire l'ajouter à l'index, en utilisant
git add
. Lorsque vous effectuez une validation, les modifications qui sont validées sont celles qui ont été ajoutées à l'index.git reset
change, au minimum, où la branche actuelle (HEAD
) pointe. La différence entre--mixed
et--soft
est de savoir si votre index est également modifié ou non. Donc, si nous sommes en branchemaster
avec cette série de commits:HEAD
pointe versC
et l'index correspondC
.Lorsque nous exécutons
git reset --soft B
,master
(et doncHEAD
) pointe maintenant versB
, mais l'index a toujours les changements deC
;git status
les montrera comme mis en scène. Donc, si nous exécutonsgit commit
à ce stade, nous obtiendrons un nouveau commit avec les mêmes modifications queC
.D'accord, alors à partir d'ici encore:
Faisons maintenant
git reset --mixed B
. (Remarque:--mixed
est l'option par défaut). Encore une fois,master
etHEAD
pointez sur B, mais cette fois, l'index est également modifié pour correspondreB
. Si nous exécutonsgit commit
à ce stade, rien ne se passera puisque l'index correspondHEAD
. Nous avons toujours les changements dans le répertoire de travail, mais comme ils ne sont pas dans l'index,git status
montrent comme non organisés. Pour les valider, vous le feriezgit add
et vous vous engagez ensuite comme d'habitude.Et enfin,
--hard
c'est la même chose que--mixed
(cela change votreHEAD
index et), sauf que cela--hard
modifie également votre répertoire de travail. Si nous sommes arrivésC
et exécutésgit reset --hard B
, les modifications ajoutéesC
, ainsi que toutes les modifications non validées que vous avez, seront supprimées et les fichiers de votre copie de travail correspondront à la validationB
. Comme vous pouvez définitivement perdre des modifications de cette façon, vous devez toujours exécutergit status
avant d'effectuer une réinitialisation matérielle pour vous assurer que votre répertoire de travail est propre ou que vous êtes d'accord avec la perte de vos modifications non validées.Et enfin, une visualisation:
la source
reset --hard
disparaissent à jamais.--mixed
modifie votre index mais pas votre répertoire de travail, donc toutes les modifications locales ne sont pas affectées.- A - B - C′
, où C ′ contient les mêmes modifications que C (avec un horodatage différent et éventuellement un message de validation). 2 et 4 vous laisseront avec- A - D
, où D contient les changements combinés de B et C.En termes simples:
--soft
: annuler les modifications, les modifications sont laissées par étapes ( index ).--mixed
(par défaut) : annuler les modifications + annuler l'étape , les modifications sont laissées dans l' arborescence de travail .--hard
: annuler l'engagement + annuler l'étape + supprimer les modifications, il ne reste plus rien.la source
Veuillez noter qu'il s'agit d'une explication simplifiée conçue comme une première étape pour chercher à comprendre cette fonctionnalité complexe.
Peut être utile pour les apprenants visuels qui souhaitent visualiser à quoi ressemble l'état de leur projet après chacune de ces commandes:
Pour ceux qui utilisent Terminal avec la couleur activée (git config --global color.ui auto):
git reset --soft A
et vous verrez les trucs de B et C en vert (mis en scène et prêts à s'engager)git reset --mixed A
(ougit reset A
) et vous verrez les trucs de B et C en rouge (non mis en scène et prêts à être mis en scène (vert) puis validés)git reset --hard A
et vous ne verrez plus les changements de B et C n'importe où (ce sera comme s'ils n'avaient jamais existé)Ou pour ceux qui utilisent un programme GUI comme «Tower» ou «SourceTree»
git reset --soft A
et vous verrez les trucs de B et C dans la zone des "fichiers intermédiaires" prêts à être validésgit reset --mixed A
(ougit reset A
) et vous verrez les trucs de B et C dans la zone des "fichiers non mis en scène" prêts à être déplacés vers mis en scène puis validésgit reset --hard A
et vous ne verrez plus les changements de B et C n'importe où (ce sera comme s'ils n'avaient jamais existé)la source
git reset
ne changeait que l'apparence degit status
la sortie de.Toutes les autres réponses sont grandes, mais je trouve qu'il valait mieux les comprendre en éliminant les fichiers en trois catégories:
unstaged
,staged
,commit
:--hard
devrait être facile à comprendre, il restaure tout--mixed
(par défaut) :unstaged
fichiers: ne pas changerstaged
fichiers: déplacer versunstaged
commit
fichiers: déplacer versunstaged
--soft
:unstaged
fichiers: ne pas changerstaged
fichiers: ne pas changercommit
fichiers: déplacer versstaged
En résumé:
--soft
l'option déplacera tout (sauf lesunstaged
fichiers) dansstaging area
--mixed
l'option déplacera tout dansunstaged area
la source
Voici une explication de base pour les utilisateurs de TortoiseGit:
git reset --soft
et--mixed
laissez vos fichiers intacts.git reset --hard
modifier réellement vos fichiers pour qu'ils correspondent au commit que vous avez réinitialisé.Dans TortoiseGit, le concept de l'index est très masqué par l'interface graphique. Lorsque vous modifiez un fichier, vous n'avez pas à exécuter
git add
pour ajouter la modification à la zone / index de transfert. Lorsqu'il s'agit simplement de modifications de fichiers existants qui ne changent pas les noms de fichiers,git reset --soft
et qui--mixed
sont les mêmes! Vous ne remarquerez une différence que si vous avez ajouté de nouveaux fichiers ou renommé des fichiers. Dans ce cas, si vous exécutez git reset --mixed, vous devrez ajouter à nouveau vos fichiers liste des fichiers non versionnés .la source
--mixed
et--soft
.Dans ces cas, j'aime un visuel qui peut, espérons-le, expliquer cela:
git reset --[hard/mixed/soft]
:Donc, chaque effet diffère
la source
Trois types de regrets
Beaucoup de réponses existantes ne semblent pas répondre à la question réelle. Ils concernent ce que font les commandes, pas ce que vous (l'utilisateur) voulez - le cas d'utilisation . Mais c'est ce que le PO a demandé!
Il pourrait être plus utile de décrire la description en termes de ce que vous regrettez précisément au moment où vous donnez une
git reset
commande. Disons que nous avons ceci:Voici quelques regrets possibles et que faire à leur sujet:
1. Je regrette que B, C et D ne soient pas un engagement.
git reset --soft A
. Je peux maintenant valider immédiatement et hop, toutes les modifications depuis A sont un commit.2. Je regrette que B, C et D ne soient pas dix commits.
git reset --mixed A
. Les validations ont disparu et l'index est de retour à A, mais la zone de travail ressemble toujours à ce qu'elle était après D. Alors maintenant, je peux ajouter et valider dans un tout autre groupe.3. Je regrette que B, C et D se soient produits sur cette branche ; Je souhaite que je m'étais branchée après A et qu'ils s'étaient produits sur cette autre branche.
Créez une nouvelle branche
otherbranch
, puisgit reset --hard A
. La branche actuelle se termine maintenant en A, avecotherbranch
son origine.(Bien sûr, vous pouvez également utiliser une réinitialisation matérielle car vous souhaitez que B, C et D ne se soient jamais produits du tout.)
la source
Vous n'avez pas à vous forcer à vous souvenir des différences entre eux. Pensez à la façon dont vous avez réellement effectué un commit.
1.Faites quelques changements.
2. ajoutez git.
3.gc -m "J'ai fait quelque chose"
Doux, Mixte et Difficile est le moyen qui vous permet de renoncer aux opérations que vous avez effectuées de 3 à 1.
Doux "fait semblant" de ne jamais voir que vous avez fait "gc -m".
Mixte "fait semblant" de ne jamais voir que vous avez fait "git add".
Difficile de «faire semblant» de ne jamais voir que vous avez modifié le fichier.
la source
Avant d'entrer dans ces trois options, il faut comprendre 3 choses.
1) Histoire / TETE
2) Stade / index
3) Répertoire de travail
reset --soft: Historique modifié, HEAD modifié, Le répertoire de travail n'est pas modifié.
reset --mixed: l'historique a changé, HEAD a changé, le répertoire de travail a été modifié avec des données non mises en scène.
reset --hard: Historique modifié, HEAD modifié, Le répertoire de travail est modifié avec des données perdues.
Il est toujours prudent d'utiliser Git --soft. On devrait utiliser une autre option dans une exigence complexe.
la source
Il y a un certain nombre de réponses ici avec une idée fausse sur
git reset --soft
. Bien qu'il existe une condition spécifique dans laquellegit reset --soft
ne changera queHEAD
(à partir d'un état de tête détaché), généralement (et pour l'utilisation prévue), il déplace la référence de branche que vous avez actuellement extraite. Bien sûr, il ne peut pas le faire si vous n'avez pas extrait une branche (d'où la condition spécifique oùgit reset --soft
ne changera queHEAD
).J'ai trouvé que c'était la meilleure façon de penser
git reset
. Vous ne vous déplacez pas seulementHEAD
( tout fait cela ), vous déplacez également la référence de branche , par exemplemaster
. Ceci est similaire à ce qui se passe lorsque vous exécutezgit commit
(la branche actuelle se déplace avecHEAD
), sauf qu'au lieu de créer (et de passer à) un nouveau commit, vous passez à un précédent commit .C'est le point de
reset
changer une branche en autre chose qu'un nouveau commit, pas de changerHEAD
. Vous pouvez le voir dans l'exemple de documentation:Quel est l'intérêt de cette série de commandes? Vous voulez déplacer une branche , ici
master
, donc pendant que vous avezmaster
vérifié, vous exécutezgit reset
.La réponse la plus votée ici est généralement bonne, mais j'ai pensé l'ajouter pour corriger les nombreuses réponses avec des idées fausses.
Changez de succursale
git reset --soft <ref>
: Remet à zéro le pointeur de branchement pour la branche a vérifié la validation , à la référence spécifiée,<ref>
. Les fichiers de votre répertoire de travail et de votre index ne sont pas modifiés. S'engager à partir de cette étape vous ramènera directement à l'endroit où vous étiez avant lagit reset
commande.Modifiez également votre index
git reset --mixed <ref>
ou équivalent
git reset <ref>
:Fait ce que
--soft
fait ET réinitialise également l'index pour qu'il corresponde à la validation à la référence spécifiée. Tandis quegit reset --soft HEAD
ne fait rien (car il dit déplacer la branche extraite vers la branche extraite),git reset --mixed HEAD
ou de manière équivalentegit reset HEAD
, est une commande courante et utile car elle réinitialise l'index à l'état de votre dernier commit.Modifiez également votre répertoire de travail
git reset --hard <ref>
: fait ce que--mixed
fait ET écrase également votre répertoire de travail. Cette commande est similaire àgit checkout <ref>
, sauf que (et c'est le point crucial à propos dereset
) toutes les formes degit reset
déplacement de la branche refHEAD
pointées par la .Une note sur "telle ou telle commande déplace la TÊTE":
Il n'est pas utile de dire qu'une commande déplace le
HEAD
. Toute commande qui change où vous vous trouvez dans votre historique de commit déplace leHEAD
. Voilà ce que l'HEAD
est , un pointeur à l' endroit où vous êtes.HEAD
c'est vous , et ainsi vous bougerez quand vous le ferez.la source
Une réponse courte dans quel contexte les 3 options sont utilisées:
Pour conserver les modifications actuelles dans le code mais pour réécrire l'historique des validations:
soft
: Vous pouvez tout valider à la fois et créer un nouveau commit avec une nouvelle description (si vous utilisez torotise git ou n'importe quelle autre interface graphique, c'est celui-ci à utiliser, car vous pouvez toujours cocher les fichiers que vous voulez dans le commit et en faire plusieurs valide de cette façon avec différents fichiers. Dans Sourcetree, tous les fichiers sont organisés pour validation.)mixed
: Vous devrez ajouter à nouveau les fichiers individuels à l'index avant de faire des commits (dans Sourcetree, tous les fichiers modifiés ne seront pas mis en scène)Pour perdre également vos modifications dans le code:
hard
: vous ne réécrivez pas seulement l'historique, mais vous perdez également toutes vos modifications jusqu'au point que vous réinitialisezla source
La différence de base entre les différentes options de la commande git reset est la suivante.
la source
--soft
: Indique à Git de réinitialiser HEAD sur un autre commit, donc l'index et le répertoire de travail ne seront en aucun cas modifiés. Tous les fichiers modifiés entre le HEAD d'origine et la validation seront organisés.--mixed
: Tout comme le soft, cela réinitialisera HEAD dans un autre commit. Il réinitialisera également l'index pour qu'il corresponde tandis que le répertoire de travail ne sera pas touché. Toutes les modifications resteront dans le répertoire de travail et apparaîtront comme modifiées, mais pas par étapes.--hard
: Cela réinitialise tout - il réinitialise HEAD à un autre commit, réinitialise l'index pour le faire correspondre et réinitialise le répertoire de travail pour le faire correspondre également.La principale différence entre
--mixed
et--soft
est de savoir si votre index est également modifié ou non. Vérifiez plus à ce sujet ici .la source
La réponse de mkarasek est excellente, en termes simples, nous pouvons dire ...
git reset --soft
: définissez leHEAD
sur la validation prévue, mais conservez vos modifications par rapport aux dernières validationsgit reset --mixed
: c'est la même chose quegit reset --soft
mais la seule différence est qu'il annule vos modifications par rapport aux dernières validationsgit reset --hard
: définissez votreHEAD
sur la validation que vous spécifiez et réinitialisez toutes vos modifications par rapport aux dernières validations, y compris les modifications non validées.la source