Share
Vous voulez savoir comment le Git réinitialiser option fonctionne?
Dans une série de cours Git sur Envato Tuts +, j'ai présenté certains des concepts fondamentaux de Git dans de simples vidéos..
Dans cette vidéo de la série, vous apprendrez tout sur la réinitialisation de Git. Vous verrez comment utiliser chaque type de réinitialisation et comment ces variétés interagissent avec les trois arbres Git:
Je vais aussi vous montrer comment utiliser git reset sur des fichiers individuels.
Git réinitialisé. Qu'est ce que ça fait? C'est la façon dont vous annulez certaines modifications locales à votre ordinateur. Lorsque vous avez effectué certains travaux dont vous avez besoin de rembobiner, réinitialisez est votre ami. Vous pouvez juste recommencer. Vous pouvez naviguer entre les contenus de divers commits et voyager un peu dans le temps..
Vous avez quelques options à votre disposition avec git reset. Vous pouvez aller fort, en douceur et mélangé, et vous pouvez également utiliser et maintenir des objets de validation ou le faire au niveau de fichier individuel.
Chacune de ces trois variantes affecte des arbres spécifiques que git utilise pour gérer vos fichiers et leur contenu..
Métaphoriquement, chaque option de réinitialisation modifie une arborescence différente, une partie différente de la façon dont git enregistre les instantanés..
Les arbres, de quoi parle-t-on ici? Git utilise le répertoire de travail, l'index (également appelé zone de transfert) et quelque chose appelé HEAD pour la création et la récupération des validations..
Le répertoire de travail vous permet de modifier les fichiers que vous pouvez insérer dans l'index. Cette zone de préparation vous permet d’affiner et de sélectionner ce que vous voulez mettre dans votre prochain commit. Un objet commit est une version cryptée du contenu de votre contenu. Il a quelques métadonnées ajoutées et des points sur les commits précédents, ce qui nous permet de voyager dans le temps..
HEAD est une référence qui pointe vers de tels objets commit. C'est simplement un pointeur qui se met à jour à chaque nouveau commit ou changement de branche. Vous pouvez le déplacer et cibler n'importe quel moment avec l'objet commit.
Pour plus d'informations sur les arbres et autres, regardez ma vidéo sur les trois arbres et Git. Il couvre le flux de travail de base dans Git et constitue une base solide pour mieux comprendre la logique d’utilisation de la réinitialisation de git..
Maintenant, regardons les différentes options.
Cela va les neuf mètres entiers. Il va d’abord déplacer HEAD et mettre à jour l’index avec le contenu du commit que HEAD pointe maintenant. Ensuite, il mettra à jour le répertoire de travail avec le contenu de l'index, détruisant ainsi éventuellement le contenu que vous avez modifié dans le répertoire de travail..
C'est donc la seule version de git reset qui soit un peu dangereuse si vous ne savez pas ce que vous faites.
Cela déplacera HEAD et mettra également à jour l'index avec le contenu du commit souhaité vers lequel HEAD ne pointe pas. Le répertoire de travail n'est pas affecté par cette opération.
L'option mixte est la valeur par défaut si vous ne fournissez pas de réinitialisation de git avec une option. Il fonctionne toujours en sécurité dans les répertoires, vous n'avez donc pas à craindre de perdre votre travail.
Cette option ne fera que déplacer HEAD et s'arrête là. En effet, cela annulera la dernière commande git commit.
Le répertoire de travail et les fichiers pouvant être stockés ne sont toujours pas affectés par cette opération..
Avec toutes ces options pour la réinitialisation de git, vous indiquez précisément à git où arrêter la lecture, en rembobinant le contenu et les fichiers des validations précédentes pour spécifier les arbres que vous souhaitez affecter. Nous pouvons aller plus loin et réinitialiser le programme avec un chemin de fichier.
Si vous utilisez un chemin, Git ne bougera pas HEAD. Pourquoi? Parce que HEAD pointe vers un objet commit et qu'il ne peut pointer que sur un sous-ensemble de celui-ci. En d'autres termes, HEAD ne pointe pas sur des fichiers spécifiques mais sur des objets de validation, composés de fichiers de bloc et de certaines métadonnées. L’index et le répertoire de travail, quant à eux, peuvent être adressés par tranches.
Seuls l'index et le répertoire de travail jouent un rôle lorsque vous utilisez un chemin. Il copie simplement le contenu d'un fichier dans l'index, et il ne peut pas faire grand chose d'autre. Git réinitialiser un fichier-fichier.ext suppose que par défaut, vous vouliez dire git reset --mixed HEAD some-file.ext et n'affectera pas le répertoire de travail.
En passant, comme HEAD ne peut pas bouger, l'option douce serait inutile. Supposons que vous travailliez sur la version 3 d'un fichier et que vous l'ajoutiez à l'index pour votre prochain commentaire. Maintenant, vous voulez dissiper ces changements. Courir Git réinitialiser un fichier-fichier.ext pour décomposer ce fichier particulier.
En conséquence, l'index sera renseigné par l'état de votre fichier à partir de la version 2, la version de votre dernier commit sur laquelle le commit de HEAD pointe. Les modifications que vous avez apportées à votre fichier, la version 3 essentiellement, sont toujours disponibles dans le répertoire de travail. Vous pouvez toujours accéder à ces modifications pour créer la version 3 de ce fichier..
Alors, que faites-vous avec Git réinitialiser un fichier-fichier.ext est-ce que vous ne manipulez que l'index.
Qu'en est-il de git reset --hard un-fichier.ext? Pourquoi ne pouvons-nous pas l'utiliser aussi??
Cette fonctionnalité est réalisée par git checkout avec un nom de fichier. git checkout some-file.ext est en fait ce que git reset --hard un-fichier.ext ferait, mais Git ne nous laisse pas utiliser l'option difficile.
Allons encore plus loin. Nous pouvons cibler n'importe quel commit pour réinitialiser un fichier spécifique, pas seulement le plus récent représenté par HEAD. Cela réinitialise les fichiers ciblés dans l'index à l'état d'un certain commit, sans affecter le répertoire de travail ni aucun commit.
Après avoir réinitialisé l’index à l’état d’un certain commit, une mise à jour rétroactive des tris, vous pouvez utiliser git checkout avec un nom de fichier pour vérifier le contenu de l'index dans votre répertoire de travail.
Pourquoi utiliser la caisse? Parce que git reset --hard avec un fichier n'est pas quelque chose que Git vous permet de faire.
Mais fais attention. En utilisant git checkout avec un chemin de fichier va se débarrasser de vos dernières modifications dans votre répertoire de travail et le remplacer par la version du fichier dans ce commit spécifique.
Si vous avez trouvé cela utile, pourquoi ne pas consulter d'autres cours Git??
Vous pouvez regarder notre introduction à Git et GitHub ou essayer les autres cours de pause-café de cette série:
Accentsconagua