Explication détaillée avec images et texte ! Comprendre comment fonctionne Git

Cet article vous apporte des connaissances pertinentes sur le principe de fonctionnement de Git, qui est principalement utilisé pour expliquer en détail avec des images et du texte. J'espère qu'il sera utile à tout le monde.

Illustration du fonctionnement de git

Cet article illustre les commandes les plus couramment utilisées dans Git. Si vous comprenez un peu le fonctionnement de Git, cet article peut vous donner une compréhension plus approfondie.

Les quatre commandes ci-dessus copient les fichiers entre le répertoire de travail, le répertoire intermédiaire (également appelé index) et l'entrepôt.

• git add files place le fichier actuel dans la zone de transit.

• git commit génère un instantané de la zone de préparation et le soumet.

• git reset – les fichiers sont utilisés pour annuler les derniers fichiers ajoutés par git. Vous pouvez également utiliser git reset pour annuler tous les fichiers de la zone de préparation.

• git checkout – files copie les fichiers de la zone de préparation vers le répertoire de travail pour ignorer les modifications locales.

Vous pouvez utiliser git reset -p, git checkout -p ou git add -p pour passer en mode interactif.

Vous pouvez également ignorer la zone de transit et récupérer directement les fichiers de l'entrepôt ou soumettre le code directement.

• git commit -a équivaut à exécuter git add pour ajouter tous les fichiers du répertoire actuel à la zone de préparation, puis à l'exécuter.

• git commit files crée un commit qui contient le dernier commit ainsi qu'un instantané des fichiers dans le répertoire de travail. Et le fichier est ajouté à la zone de transit.

• git checkout HEAD – restauration des fichiers pour copier le dernier commit.

Les images seront utilisées sous la forme suivante dans l'article suivant.

Les caractères verts à 5 chiffres représentent l'ID soumis, qui pointe respectivement vers le nœud parent. Les branches sont affichées en orange et pointent vers des commits spécifiques. La branche actuelle est identifiée par le HEAD qui lui est attaché. Cette image montre les 5 dernières soumissions, ed489 est la dernière soumission. La branche master pointe vers cette validation et l'autre branche maint pointe vers le nœud de validation grand-parent.

Diff

Il existe de nombreuses façons de voir les changements entre les commits, voici quelques exemples.

Commit

Lors de la soumission, Git crée une nouvelle soumission en utilisant les fichiers de la zone de préparation et définit le nœud à ce moment-là comme nœud parent. Pointez ensuite la branche actuelle vers le nouveau nœud de validation. Dans l'image ci-dessous, la branche actuelle est master. Avant d'exécuter la commande, master pointe vers ed489. Après la soumission, master pointe vers le nouveau nœud f0cec avec ed489 comme nœud parent.

Même si la branche actuelle est le nœud grand-parent d'une certaine soumission, git fonctionnera de la même manière. Dans la figure ci-dessous, une validation est effectuée sur la branche maint, le nœud grand-père de la branche master, et 1800b est généré. De cette façon, la branche maint n’est plus la grand-parente de la branche master. À ce stade, la fusion de [1] (ou le rebasage de [2]) est nécessaire.

Si vous souhaitez modifier un commit, utilisez git commit –amend. Git effectuera une nouvelle validation en utilisant le même nœud parent que la validation actuelle, et l'ancienne validation sera annulée.

Un autre exemple consiste à séparer la soumission HEAD [3], qui sera discutée plus tard.

Checkout

La commande Checkout est utilisée pour copier des fichiers des soumissions historiques (ou de la zone de préparation) vers le répertoire de travail, et peut également être utilisée pour changer de branche.

Lorsqu'un nom de fichier est donné (ou que l'option -p est activée, ou que le nom de fichier et l'option -p sont activées en même temps), Git copiera le fichier du commit spécifié vers la zone de préparation et travaillera annuaire. Par exemple, git checkout HEAD~ foo.c copiera foo.c dans le nœud de soumission HEAD~ (c'est-à-dire le nœud parent du nœud de soumission actuel) dans le répertoire de travail et l'ajoutera à la zone de préparation. (Si aucun nœud de validation n'est spécifié dans la commande, le contenu sera copié depuis la zone de transit.) Notez que la branche actuelle ne changera pas.

Lorsque le nom du fichier n'est pas spécifié, mais qu'une branche (locale) est donnée, alors l'identification HEAD sera déplacée vers cette branche (c'est-à-dire que nous "basculons" vers cette branche), puis la zone de préparation et le répertoire de travail will Le contenu sera cohérent avec le nœud de soumission correspondant à HEAD. Tous les fichiers du nouveau nœud de soumission (a47c3 dans la figure ci-dessous) seront copiés (dans la zone de préparation et le répertoire de travail) ; les fichiers qui n'existent que dans l'ancien nœud de soumission (ed489) seront supprimés ; au-dessus de deux fichiers seront ignorés et ne seront pas affectés.

Si ni un nom de fichier ni un nom de branche n'est spécifié, mais une étiquette, une branche distante, une valeur SHA-1 ou quelque chose de similaire comme master~3, vous obtiendrez une branche anonyme appelée HEAD détachée (identifiant HEAD détaché) . Cela facilite le basculement entre les versions historiques. Par exemple, si vous souhaitez compiler la version 1.6.6.1 de Git, vous pouvez exécuter git checkout v1.6.6.1 (il s'agit d'une étiquette, pas d'un nom de branche), compiler, installer, puis revenir à une autre branche, telle que en tant que maître de paiement git. Cependant, lorsqu'une opération de validation implique un "HEAD détaché", le comportement est légèrement différent, comme détaillé ci-dessous.

Suivez le compte public "Java Backend Technology Full Stack", répondez à l'interview et obtenez des informations d'entretien de haute qualité

Soumettre l'opération lorsque l'identifiant HEAD est dans un état détaché

Lorsque HEAD est dans un état détaché (non attaché à aucune branche), l'opération de validation fonctionne normalement, mais les branches nommées ne sont pas mises à jour. (Vous pouvez considérer cela comme la mise à jour d'une branche anonyme.)

Une fois que vous passez à une autre branche, telle que master, alors ce nœud de validation ne sera (probablement) plus jamais référencé, et il sera ensuite ignoré. Notez que rien ne fera référence à 2eecb après cette commande.

Cependant, si vous souhaitez enregistrer cet état, vous pouvez utiliser la commande git checkout -b name pour créer une nouvelle branche.

Reset

La commande Reset pointe la branche actuelle vers un autre emplacement et modifie de manière sélective le répertoire de travail et l'index. Également utilisé pour copier des fichiers du référentiel historique vers l'index sans toucher au répertoire de travail.

Si aucune option n'est proposée, alors la branche actuelle pointe vers ce commit. Si l'option –hard est utilisée, le répertoire de travail est également mis à jour, et si l'option –soft est utilisée, il reste inchangé.

Si le numéro de version du point de soumission n'est pas renseigné, HEAD sera utilisé par défaut. De cette façon, le point de branchement reste inchangé, mais l'index sera restauré au dernier commit. Si l'option –hard est utilisée, il en va de même pour le répertoire de travail.

Si un nom de fichier (ou l'option -p) est donné, l'effet de travail est similaire à une extraction avec un nom de fichier, sauf que l'index est mis à jour.

Merge

La commande Merge fusionne différentes branches. Avant la fusion, l'index doit être le même que le commit actuel. Si une autre branche est le grand-parent du commit actuel, la commande de fusion ne fera rien. Une autre situation est si le commit actuel est le grand-parent d'une autre branche, ce qui provoque une fusion rapide. Le pointeur est simplement déplacé et un nouveau commit généré.

Sinon c’est une vraie fusion. Par défaut, une fusion à trois voies est effectuée entre le commit actuel (ed489 illustré ci-dessous) et un autre commit (33104) et leur nœud grand-parent commun (b325c) [4]. Le résultat est de sauvegarder d'abord le répertoire et l'index actuels, puis d'effectuer une nouvelle validation avec le nœud parent 33104. La commande

Cherry Pick

cherry-pick "copie" un nœud de validation et effectue un nouveau commit identique sur la branche actuelle.

Rebase

Rebase est une alternative à la fusion de commandes. La fusion fusionne deux branches parentes en une seule validation, et l'historique des validations n'est pas linéaire. Le rebasage relit l'historique d'une autre branche sur la branche actuelle et l'historique des validations est linéaire. Il s’agit essentiellement d’une sélection automatique linéarisée.

Les commandes ci-dessus sont toutes exécutées dans la branche topic, pas dans la branche master. Répétez sur la branche master et pointez la branche vers le nouveau nœud. Notez que l'ancien commit n'est pas référencé et sera recyclé.

Pour limiter la portée de la restauration, utilisez l'option –on. La commande suivante rejoue les derniers commits de la branche actuelle depuis 169a6 sur la branche master, qui est 2c33a.

Il existe également git rebase –interactive, qui vous permet d'effectuer certaines opérations complexes plus facilement, telles que supprimer, réorganiser, modifier et fusionner des commits. Il n'y a aucune image montrant cela, voir ici pour plus de détails : git-rebase(1)[5].

Le contenu du fichier n'est pas réellement stocké dans l'index (.git/index) ou dans l'objet de soumission, mais est stocké dans la base de données (.git/objects) sous forme de blobs et vérifié avec les valeurs SHA-1. Le fichier d'index répertorie les fichiers blob associés et d'autres données avec des identifiants. Pour les soumissions, elles sont stockées sous forme d’arborescence et sont également identifiées par leurs valeurs de hachage. L'arborescence correspond au dossier dans le répertoire de travail, et l'arborescence ou l'objet blob contenu dans l'arborescence correspond au sous-répertoire et au fichier correspondants. Chaque soumission stocke le code d'identification de son arborescence de niveau supérieur.

Si vous soumettez en utilisant un HEAD détaché, la dernière soumission sera référencée par le reflog pour HEAD. Mais il devient invalide après un certain temps et est finalement recyclé, un peu comme git commit –amend ou git rebase.

Apprentissage recommandé : "Tutoriel Git"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!