Git Commit : une classe de maître
Résumé : 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.
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 les 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 consiste à 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 la commande add. En fait, la commande add fait un 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, à l'aide de la commande commit. C'est là que la commande add réapparaît dans notre workflow. Nous utilisons la commande add pour indiquer à Git quels fichiers modifiés nous voulons inclure dans l'instantané. Ensuite, nous utilisons commit pour indiquer à 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 l'option --global.
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 l'option --global.
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.
La commande commit référence et utilise ces valeurs lors de son fonctionnement.
Utilisation de la commande commit
L'utilisation de base de la commande commit 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 allons utiliser la commande add pour préparer le fichier, puis le valider. Nous utilisons l'option -m (message de validation) afin de pouvoir 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 la commande git log nous pouvons revoir 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 en 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 préparation de nombreux fichiers peut prendre un peu de temps. Une approche différente consiste à utiliser l'option -A (all) avec add.
Cela organise automatiquement tous les fichiers modifiés avec tous les fichiers actuellement non suivis. 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 que vous ne voulez pas inclure. Enfin, les fichiers de l'index qui ne sont plus dans le répertoire de travail sont supprimés de l'index.
De toute évidence, l'option -A peut provoquer beaucoup de choses à la fois. L'option --dry-run 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. Continuons et utilisons l'option -A avant d'utiliser la commande commit.
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
La commande commit a une option -a (tout) en minuscules. Cela effectue la mise en scène et la validation des fichiers en une seule étape.
L'option commit -a met en scène et valide les fichiers existants modifiés, et supprime les fichiers de l'index s'ils ont été supprimés de votre répertoire de travail. Il ne met pas en scène automatiquement les fichiers non suivis.
Comme la commande add, la commande commit a une option --dry-run 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 la commande Git stash 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 la commande pop plutôt que la commande apply. La commande pop applique les modifications et les supprime également de la réserve.
Nous avons apporté quelques modifications à la branche new-parser de notre référentiel. Elles auraient dû être faites dans la branche classic-parser.
git stash
git checkout classic-parser
git stash pop
Nous pouvons maintenant effectuer un commit, et mettre à jour cette branche.
git commit -a -m "Added pre-parser functions"
Si nous revenons à la branche new-parser, nous pouvons voir qu'elle 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 l'option --amend pour arranger les choses. 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 le voir.
Pour corriger cela, nous utiliserons l'option --amend 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 préparer le fichier, puis effectuerons un commit avec l'option --amend. L'option --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. 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 la commande reset --soft. 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 la commande reset --mixed. 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 le trouver en utilisant git log :
Copiez cette référence et utilisez-la dans la commande revert :
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
De toute évidence, 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.