Utilisation de base
Les quatre commandes ci-dessus copient des fichiers entre le répertoire de travail, le répertoire de préparation (aussi appelé index), et le dépôt.
git add filesPlacer le fichier actuel dans la zone de préparation.git commitGénérer un instantané de la zone de préparation et effectuer un commit.git reset -- filesUtilisé pour annuler le derniergit add files, vous pouvez aussi utilisergit resetpour annuler tous les fichiers de la zone de préparation.git checkout -- filesCopier les fichiers de la zone de préparation vers le répertoire de travail pour abandonner les modifications locales.
Vous pouvez utilisergit reset -p, git checkout -p, ou git add -ppour entrer en mode interactif.
Vous pouvez également ignorer la zone de préparation et récupérer directement les fichiers depuis le dépôt ou valider directement le code.
git commit -aÉquivalent à exécutergit addajouter tous les fichiers du répertoire courant à la zone de préparation puis exécuter.git commit.git commit filesEffectuer un commit qui inclut le dernier commit ainsi qu'un instantané des fichiers du répertoire de travail. Et les fichiers sont ajoutés à la zone de préparation.git checkout HEAD -- filesRevenir en arrière pour copier le dernier commit.
Conventions
Dans le texte qui suit, les images sont utilisées sous la forme ci-dessous.
Les chaînes vertes de 5 caractères représentent les ID de commit, pointant respectivement vers leurs nœuds parents. Les branches sont affichées en orange, chacune pointant vers un commit spécifique. La branche actuelle est identifiée par l'identifiantHEAD. Cette image montre les 5 derniers commits,ed489est le dernier commit. La branchemasterpointe vers ce commit, une autre branchemaintpointe vers le nœud de commit grand-parent.
Détails de la commande
Diff
Il existe de nombreuses façons de visualiser les différences entre deux commits. Voici quelques exemples.
Commit
Lors d'un commit, git utilise les fichiers de la zone de préparation pour créer un nouveau commit, et définit le nœud actuel comme nœud parent. Ensuite, il pointe la branche actuelle vers le nouveau nœud de commit. Dans la figure ci-dessous, la branche actuelle estmaster. Avant d'exécuter la commande,masterpointe versed489, après le commit,masterpointe vers le nouveau nœudf0cecet utiliseed489comme nœud parent.
Même si la branche actuelle est le grand-parent d'un commit, git fait de même. Dans la figure ci-dessous, au nœud grand-parentmasterde la branche,maintun commit est effectué sur la branche, générant1800b. De cette façon,maintla branche n'est plusmasterle nœud grand-parent de la branche. À ce stade, une fusion (ou un rebasage) est nécessaire.
Si vous voulez modifier un commit, utilisezgit commit --amend. git créera un nouveau commit en utilisant le même nœud parent que le commit actuel, et l'ancien commit sera annulé.
Un autre exemple est un commit HEAD détaché, qui sera abordé plus tard.
Extraction
La commande checkout est utilisée pour copier des fichiers depuis un commit historique (ou la zone de préparation) vers le répertoire de travail, et peut aussi ê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és ensemble), git copie les fichiers du commit spécifié vers la zone de staging et le répertoire de travail. Par exemple,git checkout HEAD~ foo.cva, à partir du nœud de commitHEAD~(c'est-à-dire le nœud parent du nœud de commit actuel),foo.ccopier le fichier dans le répertoire de travail et l'ajouter à la zone de staging. (Si aucun nœud de commit n'est spécifié dans la commande, le contenu est copié depuis la zone de staging.) Notez que la branche actuelle ne change pas.
Lorsqu'aucun nom de fichier n'est spécifié, mais qu'une branche (locale) est donnée, alors l'identifiantHEADse déplace vers cette branche (c'est-à-dire que nous "basculons" vers cette branche), puis le contenu de la zone de préparation et du répertoire de travail seraHEADcohérent avec le nœud de commit correspondant. Tous les fichiers du nouveau nœud de commit (a47c3 dans la figure ci-dessous) seront copiés (vers la zone de préparation et le répertoire de travail) ; les fichiers qui n'existent que dans l'ancien nœud de commit (ed489) seront supprimés ; les fichiers qui n'appartiennent à aucun des deux ci-dessus seront ignorés et non affectés.
Si ni un nom de fichier ni un nom de branche n'est spécifié, mais plutôt une étiquette, une branche distante, une valeur SHA-1, ou quelque chose de similaire àmaster~3, vous obtenez une branche anonyme, appeléedetached HEAD(detachedHEADidentifiant). Cela permet de basculer facilement entre les versions historiques. Par exemple, si vous souhaitez compiler la version 1.6.6.1 de git, vous pouvez exécutergit checkout v1.6.6.1(ceci est une étiquette, pas un nom de branche), compilez, installez, puis revenez à une autre branche, par exemplegit checkout master. Toutefois, lorsqu'une opération de commit implique un « HEAD détaché », son comportement est légèrement différent ; voir ci-dessous pour plus de détails.
Opérations de commit lorsque l'identifiant HEAD est dans un état détaché
LorsqueHEADLorsqu'il est dans un état détaché (non attaché à aucune branche), les opérations de commit peuvent se dérouler normalement, mais aucune branche nommée n'est mise à jour. (Vous pouvez considérer cela comme la mise à jour d'une branche anonyme.)
Une fois que vous passez ensuite à une autre branche, par exemplemaster, ce nœud de commit pourrait ne plus jamais être référencé et sera abandonné. Notez qu'après cette commande, rien ne référencera2eecb。
Mais si vous voulez sauvegarder cet état, vous pouvez utiliser la commandegit checkout -b namepour créer une nouvelle branche.
Réinitialiser
La commande reset fait pointer la branche courante vers un autre emplacement et modifie sélectivement le répertoire de travail et l'index. Elle est également utilisée pour copier des fichiers du dépôt historique vers l'index sans modifier le répertoire de travail.
Si aucune option n'est donnée, la branche courante pointe vers ce commit. Si l'--hardoption est utilisée, le répertoire de travail est également mis à jour ; si l'--softoption est utilisée, aucun des deux ne change.
--hardoption est utilisée, le répertoire de travail est également le même.
Si un nom de fichier est donné (ou-poption), l'effet est similaire à checkout avec un nom de fichier, sauf que l'index est mis à jour.
Tri fusion
La commande merge fusionne différentes branches. Avant la fusion, l'index doit être identique au commit actuel. Si une autre branche est le grand-parent du commit actuel, la commande merge ne fera rien. L'autre cas est si le commit actuel est le grand-parent d'une autre branche, ce qui donne unfast-forwardfusion. Le pointeur se déplace simplement et ne génère pas de nouveau commit.
Sinon, il s'agit d'une véritable fusion. Par défaut, le commit actuel (ed489comme indiqué ci-dessous) et un autre commit (33104) ainsi que leur nœud grand-parent commun (b325c) effectuent unefusion à trois voies.. Le résultat est que le répertoire courant et l'index sont d'abord enregistrés, puis avec le nœud parent33104un nouveau commit est créé.
Cherry Pick
La commande cherry-pick « copie » un nœud de commit et crée un nouveau commit identique sur la branche actuelle.
Rebase
Le rebasage est une alternative à la commande merge. Merge combine deux branches parentes en un seul commit, et l'historique des commits n'est pas linéaire. Le rebasage rejoue l'historique d'une autre branche sur la branche actuelle, ce qui rend l'historique des commits linéaire. En substance, c'est un cherry-pick automatisé qui linéarise.
Les commandes ci-dessus sont toutes effectuées sur la branchetopic, et non la branchemaster; sur lamasterbranche, ils sont rejoués, et la branche pointe vers le nouveau nœud. Notez que les anciens commits ne sont pas référencés et seront récupérés.
Pour limiter la plage de retour en arrière, utilisez l’--ontooption. La commande suivante, sur la branchemaster, rejoue la branche courante depuis169a6les commits récents, c’est-à-dire,2c33a。
Il y a aussigit rebase --interactivepour vous permettre de réaliser plus facilement certaines opérations complexes, telles que l’abandon, la réorganisation, la modification et la fusion de commits. Aucune image ne les illustre ; voir ici pour plus de détails :git-rebase(1)
Notes techniques
Le contenu des fichiers n’est pas réellement stocké dans l’index (.git/index) ni dans les objets de commit, mais il est stocké séparément dans la base de données sous forme de blobs (.git/objects), et il est vérifié avec des valeurs SHA-1. Le fichier d’index utilise des codes d’identification pour lister les fichiers blob pertinents et d’autres données. Pour les commits, ils sont stockés dans un arbre (tree, également identifié par la valeur de hachage correspondante. Les arbres correspondent aux dossiers du répertoire de travail, et les arbres ou objets blob contenus dans un arbre correspondent aux sous-répertoires et fichiers correspondants. Chaque commit stocke le code d’identification de son arbre parent.
Si vous committez avec un HEAD détaché, le dernier commit sera référencé par le reflog de HEAD. Mais il devient invalide au bout d’un moment et est finalement récupéré, semblable àgit commit --amendougit rebasepar nature.
Lien original : http://marklodato.github.io/visual-git-guide/index-zh-cn.html