Git Commit : une classe de maître
La commande Git commit stocke des copies des modifications de votre répertoire de travail dans votre référentiel Git. Mais il peut également être utilisé pour modifier des commits existants et pour annuler des commits.
Une exigence de base de tout système de contrôle de version est de stocker différentes versions de fichiers pour vous. Dans Git, la commande qui fait cela est commit. Voici tout ce que vous devez savoir.
Sommaire
Qu’est-ce qu’un commit dans Git ?
Les commits sont la série d’instantanés réalisés tout au long du cycle de vie d’un projet qui constituent son historique de développement. Les commits sont ce qui nous permet d’extraire une version du projet tel qu’il était à différents moments dans le passé. Pourquoi est-ce important ?
Les systèmes de contrôle de version (VCS) sont le plus souvent utilisés avec le code source des logiciels et les projets de développement. Mais ils peuvent être utilisés avec succès avec n’importe quelle collection de fichiers texte, tels que les fichiers Markdown contenant des chapitres d’un livre.
Vous ne souhaitez peut-être pas que tous les fichiers de vos répertoires de projet soient gérés par le VCS, vous devez donc être en mesure de nommer les fichiers dont vous souhaitez contrôler la version. Cela les ajoute à la vue de contrôle de version du projet. Ils seront surveillés pour les changements.
Une autre façon d’y parvenir est d’utiliser une liste d’ignorés. Cela indique à Git quels fichiers, répertoires ou types de fichiers il doit toujours ignorer.
Au fil du temps, à mesure que de nouveaux fichiers sont ajoutés au projet, certains devront être ajoutés au système de contrôle de version. Dans Git, cela est géré par le add commande. En fait, le add commande double service, comme nous le verrons.
Afin de conserver un historique des modifications apportées au projet, vous demanderez périodiquement à Git de stocker un instantané de l’état du projet, en utilisant le commit commande. C’est là que le add commande réapparaît dans notre flux de travail. Nous utilisons le add commande pour indiquer à Git quel modifié fichiers que nous voulons inclure dans l’instantané. Ensuite on utilise commit pour dire à Git de créer l’instantané.
Configuration de la commande commit
Les informations sur le commit sont stockées avec lui, de sorte qu’il est toujours possible de savoir qui a fait le commit, quand et ce que le commit contient. Certaines de ces métadonnées sont capturées au moment de la validation, comme le message de validation.
Les métadonnées relatives à l’identité des membres de l’équipe de développement peuvent être paramétrées par chaque utilisateur, pour éviter de fournir à plusieurs reprises les mêmes informations.
Pour définir votre nom globalement pour tous les référentiels de votre ordinateur, utilisez cette commande.
git config --global user.name "Dave McKay"
Pour vérifier que votre nom a été défini, utilisez cette commande.
git config --global user.name
Si vous devez utiliser un nom différent sur un référentiel particulier, accédez au répertoire du projet et utilisez la même commande sans le --global option.
git config user.name "McKay, David"
git config user.name
Nous avons maintenant un nom d’utilisateur par défaut différent pour ce référentiel, et notre nom global est toujours utilisé pour d’autres référentiels.
De la même manière, nous pouvons définir une adresse e-mail soit globalement, soit pour un seul référentiel en incluant ou en omettant le --global option.
git config user.email "dave@phony-domain.com"
git config --global user.email "dave@fake-domain.com"
git config user.email
git config --global user.email
Ces paramètres sont conservés dans des fichiers de configuration. Les paramètres globaux de Git sont conservés dans « ~/.gitconfig », et les paramètres spécifiques au référentiel sont conservés dans le fichier « .git/config » du référentiel.
Le commit la commande référence et utilise ces valeurs pendant son fonctionnement.
Utilisation de la commande commit
L’utilisation de base de la commit La commande consiste à prendre les fichiers qui se trouvent dans la zone de staging, connue sous le nom d’index, et à les stocker en tant que validation dans la branche actuelle du référentiel.
Un engagement de base
Nous avons un projet avec un fichier modifié. Nous utiliserons le add commande pour mettre en scène le fichier, puis validez-le. Nous utilisons le -m (message de validation) afin que nous puissions fournir une brève description de l’objectif des modifications. Si nous n’utilisons pas cette option, nous sommes invités à envoyer un message de validation lors de la validation. Il est plus pratique d’en ajouter un sur la ligne de commande.
git add jibber.c
git commit -m "Updated help text"
Si nous utilisons le git log commande, nous pouvons examiner les détails des commits, dans l’ordre chronologique, avec le commit le plus récent en haut de la liste.
git log
Les commits sont affichés dans less.
Le commit a été étiqueté avec le nom et l’adresse e-mail que nous avons fournis précédemment, et notre message de commit est également enregistré.
Fichiers de mise en scène automatique
La mise en scène de nombreux fichiers peut prendre un peu de temps. Une approche différente consiste à utiliser le -A (toutes) options avec add.
Cela met automatiquement en scène tous modifié fichiers avec tous actuellement non suivi des dossiers. La mise en scène des fichiers non suivis respecte les paramètres de votre fichier « .gitignore ». Git ne mettra pas en scène les fichiers que vous lui avez dit de ne pas inclure. Enfin, les fichiers de l’index qui ne sont plus dans le répertoire de travail sont supprimé de l’indice.
En clair, le -A option peut provoquer beaucoup de choses à la fois. Le --dry-run L’option vous donne un aperçu des modifications sans les effectuer réellement.
git add -A --dry-run
Dans notre exemple, il mettra en scène deux fichiers existants modifiés et deux nouveaux fichiers. Allons-y et utilisons le -A option avant d’utiliser le commit commande.
git add -A
git commit -m "Enhanced parsing"
Nous pouvons voir qu’en tout quatre fichiers sont modifiés. Deux d’entre eux sont les fichiers nouvellement créés, qui sont répertoriés.
Mise en scène et engagement en même temps
Le commit la commande a une minuscule -a (toutes) options. Cela effectue la mise en scène et la validation des fichiers en une seule étape.
Le commit -a étapes d’option et commits modifiés existant fichiers, et supprime fichiers de l’index s’ils ont été supprimés de votre répertoire de travail. Il n’a pas organiser automatiquement les fichiers non suivis.
Comme le add commande, la commande commit a une --dry-run option qui vous permet de prévisualiser ses actions avant de l’exécuter.
git commit -a --dry-run
Exécutons maintenant la commande.
git commit -a --dry-run
Les fichiers sont mis en scène et validés pour nous.
S’engager dans une branche différente
Si vous avez apporté des modifications aux fichiers de votre répertoire de travail, puis réalisez que vous n’avez pas extrait la bonne branche, vous devez valider vos modifications dans la bonne branche sans affecter la branche actuelle.
Git n’a pas de commande pour s’engager dans une branche différente. Mais vous pouvez rectifier cette situation avec un peu de dextérité Git.
Nous utiliserons le Git stash commande pour faire une copie des modifications. Ensuite, nous vérifierons la bonne branche et appliquerons les modifications à partir de la réserve. Pour appliquer les modifications cachées, nous utilisons le pop commande plutôt que le apply commande. Le pop La commande applique les modifications et les supprime également de la réserve.
Nous avons apporté quelques modifications à notre référentiel new-parser bifurquer. Ils auraient dû être faits dans le classic-parser bifurquer.
git stash
git checkout classic-parser
git stash pop
Nous pouvons maintenant effectuer une commitet mettez à jour cette branche.
git commit -a -m "Added pre-parser functions"
Si nous revenons à la new-parser branch, nous pouvons voir qu’il est à jour, ce qui signifie que les modifications ont été supprimées de votre répertoire de travail et que votre référentiel et vos fichiers sont synchronisés.
git checkout new-parser
git status
Apporter des modifications aux commits
Si vous avez besoin d’améliorer votre message de commit (peut-être y avez-vous repéré une faute de frappe) ou si vous avez oublié de mettre en scène un fichier qui aurait dû être inclus dans le commit, vous pouvez utiliser le --amend possibilité de redresser la situation. La mise en garde est que cela ne devrait pas être utilisé sur les commits qui ont été poussés vers un référentiel distant.
Dans notre dernier message de validation, « fraze » aurait dû être « phrase ». Si nous utilisons git log nous pouvons voir cela.
Pour corriger cela, nous utiliserons le --amend option comme celle-ci.
git commit --amend -m "Optimized phrase identification"
Si nous utilisons git log une fois de plus, nous pouvons voir que l’ancien commit a été remplacé par un nouveau avec le message de commit corrigé.
Si nous voulons ajouter un fichier que nous avons oublié de mettre en scène, nous pouvons valider ce fichier afin qu’il apparaisse dans le cadre du commit précédent.
Nous utiliserons add pour mettre en scène le fichier, puis faites un commit avec le --amend option. Le --no-edit signifie que nous n’avons pas besoin de fournir un nouveau message de validation. Le message de validation précédent est conservé.
git add jibber.c
git commit --amend --no-edit
Supprimer les modifications d’un commit
Si vous avez par inadvertance mis en scène et validé un fichier que vous n’aviez pas l’intention de faire, vous pouvez supprimer ce fichier de la validation à l’aide de la commande reset commande. Nous allons réinitialiser le commit dans la zone de staging, ou index. Ensuite, nous supprimerons le fichier et validerons à nouveau le reste des fichiers.
Pour réinitialiser le dernier commit dans la zone de staging, nous utilisons le reset --soft commande. HEAD~ est un raccourci pour « le commit derrière le HEAD de la chronologie de commit du projet », ou en anglais, « le dernier commit ».
git reset --soft HEAD~
Pour supprimer le fichier qui n’aurait pas dû être inclus, nous utilisons le reset --mixed commande. Cela réinitialise ces modifications dans le répertoire de travail, recréant le fichier modifié en tant que fichier non préparé et non validé.
git reset --mixed jibber.c
Nous devons valider les autres fichiers qui restent dans l’index.
git commit -m "Experimental tweaks"
Les deux autres fichiers qui étaient dans le commit d’origine sont ré-engagés pour nous.
Annuler un commit entier
Parfois, annuler un commit entier est la chose la plus facile à faire. Il remet votre répertoire de travail et votre référentiel à l’état dans lequel ils se trouvaient avant la validation.
Nous devons utiliser l’ID de référence haché du commit. Nous pouvons trouver cela en utilisant git log:
Copiez cette référence et utilisez-la dans le revert commande:
git revert e5bd4560aef8164c6ca9d6d4620b9db7f66aecc8
Cela ouvrira votre éditeur par défaut afin que vous puissiez modifier un message de retour. Un message par défaut est entré pour vous. Vous pouvez soit l’utiliser, soit le modifier à votre guise.
Lorsque vous êtes satisfait de votre message de retour, enregistrez le fichier et quittez l’éditeur. Dans nano, vous faites cela avec « Ctrl + O » et « Ctrl + X ».
En utilisant git log une fois de plus, nous pouvons voir qu’un nouveau commit a été ajouté qui annule les modifications du commit annulé.
Le couteau suisse Git
Évidemment, commit est l’une des commandes Git les plus importantes. Il peut faire beaucoup, donc il y a beaucoup à apprendre. Se familiariser avec ses fonctionnalités moins utilisées est du temps bien dépensé. Lorsque vous avez besoin de corriger une erreur, tout de suite, vous serez content de vous être préparé à l’avance.
