Question Quelle est la différence entre git reset --mixed, --soft et --hard?


Je cherche à diviser un commit et je ne sais pas quelle option de réinitialisation utiliser.

Je regardais la page Pouvez-vous expliquer ce que "git reset" fait en anglais?, mais je me suis rendu compte que je ne comprenais pas vraiment ce qu'est la zone d'indexation ou la zone de stadification et donc les explications n'ont pas aidé.

Aussi les cas d'utilisation pour --mixed et --soft ressemble à moi dans cette réponse (quand vous voulez réparer et recommencer) Est-ce que quelqu'un peut encore mieux le décomposer? je réalise --mixed est probablement l'option à suivre, mais je veux savoir Pourquoi. Enfin, qu'en est-il --hard?

Quelqu'un peut-il me donner un exemple de flux de travail sur la manière de sélectionner les trois options?


506
2017-08-20 04:41


origine


Réponses:


Lorsque vous modifiez un fichier dans votre référentiel, la modification est initialement non structurée. Pour le valider, vous devez l'activer, c'est-à-dire l'ajouter à l'index en utilisant git add. Lorsque vous effectuez une validation, les modifications validées sont celles qui ont été ajoutées à l'index.

git reset changements, au minimum, lorsque la branche actuelle (HEAD) pointe. La différence entre --mixed et --soft est si oui ou non votre index est également modifié. Donc, si nous sommes sur une branche master avec cette série de commits:

- A - B - C (master)

HEADpointe vers C et l'index correspond C.

Quand nous courons git reset --soft B, master (Et ainsi HEAD) indique maintenant B, mais l'indice a encore les changements de C; git status les montrera comme mis en scène. Donc si nous courons git commit à ce stade, nous allons obtenir un nouveau commit avec les mêmes changements que C.


D'accord, donc à partir d'ici encore:

- A - B - C (master)

Maintenant, faisons git reset --mixed B. (Remarque: --mixed est l'option par défaut). Encore une fois, master et HEAD pointez sur B, mais cette fois, l’index est également modifié pour correspondre B. Si nous courons git commit à ce stade, rien ne se passera puisque l'index correspond HEAD. Nous avons toujours les changements dans le répertoire de travail, mais comme ils ne sont pas dans l'index, git status les montre comme non statiques. Pour les commettre, vous auriez git add puis commettez comme d'habitude.


Et enfin, --hard est le même que --mixed (ça change votre HEAD et index), sauf que --hard modifie également votre répertoire de travail. Si nous sommes à C et courir git reset --hard B, puis les changements ajoutés dans C, ainsi que tous les changements non validés que vous avez, seront supprimés et les fichiers de votre copie de travail correspondront à commit B. Puisque vous pouvez perdre définitivement les changements de cette façon, vous devriez toujours courir git status avant de procéder à une réinitialisation matérielle pour vous assurer que votre répertoire de travail est propre ou que vous êtes prêt à perdre vos modifications non validées.


Et enfin, une visualisation: enter image description here


1024
2017-08-20 05:53



S'il vous plaît soyez conscient, ceci est une explication simplifiée destinée dans un premier temps à chercher à comprendre cette fonctionnalité complexe.

Peut être utile pour les apprenants visuels qui veulent visualiser à quoi ressemble leur état de 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 Aet vous verrez les choses de B et C en vert (mises en scène et prêtes à commettre)

git reset --mixed A (ou git reset A) et vous verrez les trucs de B et C en rouge (non mis en scène et prêt à être mis en scène (vert) et ensuite commis)

git reset --hard A et vous ne verrez plus les changements de B et C partout (ce sera comme s'ils n'avaient jamais existé)


Ou pour ceux qui utilisent un programme graphique comme 'Tower' ou 'SourceTree'

git reset --soft A et vous verrez les choses de B et C dans la zone 'fichiers mis en scène' prêt à commettre

git reset --mixed A (ou git reset A) et vous verrez les choses de B et C dans la zone 'fichiers non stockés' prêts à être déplacés à mis en scène et ensuite commis

git reset --hard A et vous ne verrez plus les changements de B et C partout (ce sera comme s'ils n'avaient jamais existé)


60
2017-11-21 12:06



Voici une explication de base pour les utilisateurs de TortoiseGit:

git reset --soft et --mixed laissez vos fichiers intacts.

git reset --hard réellement changer vos fichiers pour correspondre au commit que vous avez réinitialisé.

Dans TortoiseGit, le concept de l'index est très caché par l'interface graphique. Lorsque vous modifiez un fichier, vous n'avez pas à exécuter git add ajouter la modification à la zone de transit / index. Quand il s'agit simplement de modifier des fichiers existants qui ne modifient pas les noms de fichiers, git reset --soft et --mixed sont identiques! Vous remarquerez seulement une différence si vous avez ajouté de nouveaux fichiers ou des fichiers renommés. Dans ce cas, si vous exécutez git reset --mixed, vous devrez ajouter à nouveau votre (vos) fichier (s) Fichiers non versionnés liste.


16
2017-10-28 20:38



En termes simples:

  • --soft: non engagé changements, les changements sont laissés en scène (indice).
  • --mixed  (défaut): uncommit + unstage changements, les changements sont laissés en arbre de travail.
  • --hard: non impliqué + instable + supprimer changements, rien à gauche.

9
2018-04-25 12:30



Une réponse courte dans quel contexte les 3 options sont utilisées:

À garder les changements actuels dans le code mais pour réécrire l'historique de commit:

  • soft: Vous pouvez tout commettre en même temps et créer un nouveau commit avec une nouvelle description (si vous utilisez toritise git ou toute autre interface graphique, c'est celui que vous utiliserez, car vous pouvez toujours cocher les fichiers que vous voulez dans le commit et faire plusieurs commet de cette façon avec différents fichiers: dans Sourcetree, tous les fichiers seraient mis en scène pour validation.)
  • mixed: Vous devrez à nouveau ajouter les fichiers individuels à l'index avant de faire des validations (dans Sourcetree, tous les fichiers modifiés seront désassemblés)

Pour réellement perdre vos changements dans le code aussi:

  • hard: vous ne réécrivez pas simplement l'histoire mais perdez aussi toutes vos modifications jusqu'au point où vous avez réinitialisé

1
2017-07-14 09:20



Avant d'entrer dans ces trois options, il faut comprendre 3 choses.

1) Histoire / HEAD

2) Stade / index

3) Répertoire de travail

reset --soft: l'historique a changé, HEAD a changé, le répertoire de travail n'a pas changé.

reset --mixed: L'historique a changé, HEAD a changé, le répertoire de travail a été modifié avec des données non stockées.

reset --hard: L'historique a changé, HEAD a changé, le répertoire de travail est modifié avec les données perdues.

Il est toujours prudent d'utiliser Git --soft. On devrait utiliser l'autre option dans l'exigence complexe.


1
2017-11-14 11:32



La différence de base entre les différentes options de la commande git reset est la suivante.

  • --soft: ne réinitialise que HEAD sur le commit sélectionné. Fonctionne essentiellement de la même manière que git checkout mais ne crée pas d'état de tête détaché.
  • --mixed (option par défaut): réinitialise HEAD sur le commit sélectionné dans l'historique et annule les modifications dans l'index.
  • --hard: réinitialise le HEAD à la validation que vous sélectionnez dans l'historique, annule les modifications dans l'index et annule les modifications dans votre répertoire de travail.

0
2018-05-21 04:27



--soft: Demande à Git de réinitialiser HEAD à une autre validation, ainsi index et le répertoire de travail ne seront pas modifiés d'aucune façon. Tous les fichiers modifiés entre le HEAD original et le commit seront mis en scène.

--mixed: Tout comme le soft, cela va réinitialiser HEAD à un autre commit. Il réinitialisera également l'index pour le faire correspondre alors 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 mises en scène.

--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.

La principale différence entre --mixed et --soft est si oui ou non votre index est également modifié. Vérifiez plus à ce sujet ici.


0
2018-05-29 10:18