Lorsqu'un développeur termine son travail sur une fonctionnalité quelconque ou lorsqu'il termine la correction d'un bogue, il doit créer une révision. Ceci signifie qu'il indiquera à Git qu'il a terminé son travail sur une liste de fichiers puis qu'il les soumettra dans le dépôt Git.
Le travail de gestion des versions sera toujours effectué localement dans un premier temps. Ce n'est qu'à la fin des étapes locales qu'il sera possible, si désiré, d'envoyer des révisions vers un serveur distant.
Concentrons-nous donc sur le travail local.
Le fonctionnement de Git peut être vulgarisé en représentant trois zones1 :
Avant de plonger plus en profondeur dans Git, il est important de faire connaissance avec quelques commandes qui nous aideront à connaître les fichiers et leur état aux yeux de Git.
Rappel : selon vos configurations, la console Git peut être une fenêtre Git Bash, une fenêtre Terminal ou encore une fenêtre Vagrant SSH.
Pour connaître les modifications depuis la dernière soumission à Git :
Dans le résultat affiché par git status, les fichiers ajoutés, modifiés ou supprimés qui ne font pas partie de l'index apparaissent en rouge. Ceux qui sont déjà ajoutés à l'index sont en vert.
Il est possible de configurer Git pour que le résultat n'apparaisse qu'une page à la fois. Une fois la première page affichée, il faudra appuyer sur Entrée pour faire défiler les autres fichiers.
git config --global pager.status true
Une autre commande utile pour connaître l'état des différents fichiers :
Sans arguments, cette commande liste tous les fichiers suivis par Git.
En lui passant différents paramètres, il est possible de connaître à peu près tout ce qu'on désire savoir.
Pour quelques exemples pratiques : https://gist.github.com/mkhairi/405c4afa2fedb7328695a7a73ef49074
Le processus de soumission d'une révision se déroule en trois étapes :
Le fichier .gitignore permet de lister les fichiers qui ne doivent jamais être suivis.
Ce sera le cas par exemple :
En temps normal, seuls les fichiers texte seront soumis à Git.
Le fichier .gitignore sera placé à la racine du dossier de votre application (et non dans le dossier .git).
Dans l'exemple suivant, les fichiers contenus dans les dossiers vendor et public/images de même que le fichier .env ne feront jamais partie de l'index, même s'ils étaient modifiés.
/vendor
/public/images
.env
Si vous ajoutez un fichier ou un dossier à .gitignore après qu'il ait été marqué parmi les fichiers suivis par Git, la commande git status continuera de le montrer.
Pour régler ce problème :
git rm --cached -r nomFichierOuDossier
Pour ajouter un fichier dans l'index, vous devez utiliser la commande git add.
Puisqu'une révision ne doit être composée que des fichiers propres à cette révision, on doit commencer par lister tous les fichiers qui ont été ajoutés, modifiés ou supprimés du répertoire de travail depuis la dernière révision.
git status
Si tous les fichiers en rouge (ce sont ceux qui ne font pas partie de l'index) doivent faire partie de la révision, il est possible d'ajouter l'ensemble des ces fichiers en utilisant l'option -A ou --all. Les fichiers listés dans .gitignore ne seront pas ajoutés.
git add --all
Si le dossier courant est la racine du projet, on obtiendra le même résultat avec git add .. Ceci indiquera à Git qu'il doit faire un suivi de tous les fichiers du dossier courant.
git add .
Dans le cas où certains des fichiers ajoutés ou modifiés ne sont pas en lien avec le travail en cours, il est possible d'ajouter les fichiers à l'index un à un.
git add app/Http/Controllers/ProduitsController.php
On peut également ajouter un dossier entier.
git add app/fonctions/
Si un fichier a été ajouté à l'index par erreur, on peut le retirer.
git reset chemin/UnFichier.txt
Une fois que des fichiers ont été ajoutés à l'index, la commande git status listera les fichiers faisant partie de la révision. Vous verrez donc, en vert, la liste des fichiers, parmi les fichiers suivis, qui ont été modifiés depuis la dernière soumission au serveur Git. Si certains des fichiers modifiés ne sont pas suivis, il apparaîtront en rouge.
Quand la liste des fichiers suivis est complète, vous pouvez soumettre la révision à Git à l'aide de la commande git commit. Vous indiquerez par la même occasion une description à accoler à l'envoi (ex : Ajouté fonctionnalité X, Corrigé bogue Y, Ajouté en-têtes standards).
Par convention, cette description débutera par une majuscule et ne comportera pas de point terminal. Elle est limitée à 49 caractères.
Cette description est importante : c'est elle qui permettra de retrouver l'état de l'application à un moment précis.
git commit -m 'Une description'
Notez qu'après un git commit, les fichiers seront automatiquement retirés de l'index puisqu'ils font maintenant partie du dépôt.
Il est possible de noter dans un fichier texte, que l'on appellera registre des modifications, les détails des modifications apportées. Un endroit approprié pour ce fichier est le dossier dev, que plusieurs développeurs utilisent pour stocker les fichiers de développement qui ne font pas partie de la solution finale. Dans ce dossier, on créera un sous-dossier revisions.
La première ligne de ce fichier texte sera la description, limitée à 49 caractères.
Les lignes suivantes peuvent être aussi longues que désiré.
Couleur boutons-Renvoi ancre-Rôle proprio
Ajusté couleurs boutons dans tableau des tests.
Renvoi à une ancre vers la bonne section après ajout ou modif. cas d'essai.
Dans liste des tests, ajouté rôle 5 = propriétaire.
On utilisera alors l'option -F pour indiquer à Git que les détails de la révision se trouvent dans un fichier.
git commit -F dev/revisions/aaaa-mm-jj.txt
Une fois la soumission complétée, vous devez vérifier si elle a effectivement été réalisée.
Pour visualiser la liste des révisions soumises à Git, incluant la description qui accompagne chaque révision :
Pour sortir de cette commande, appuyez sur Ctrl + z.
Il est possible de lister les détails de la dernière révision. On y verra alors la liste des fichiers modifiés avec, pour chacun, le nombre de lignes ajoutées et le nombre de lignes supprimées :
git log -1 --stat
Et pour s'assurer qu'il n'y a plus de différences entre le répertoire de travail et la dernière révision soumise à Git :
git diff HEAD
Si les modifications ont bien été soumises et que tous les fichiers modifiés faisaient partie de la révision, la commande git diff HEAD ne produira aucune sortie, ce qui signifie que le répertoire de travail et la dernière révision sont identiques.
Vous venez de faire un git commit et vous désirez revenir en arrière? Ceci est possible tant que vous n'avez pas fait de git push pour copier vos révisions sur un serveur Git distant.
La commande suivante permet de prendre les fichiers qui ont été ajoutés au dépôt lors du dernier commit et de les ramener dans l'index.
L'argument HEAD~1 indique que vous désirez travailler avec la soumission juste avant le HEAD donc la dernière soumission.
git reset --soft HEAD~1
À partir de ce moment, vous pouvez ajouter des fichiers à l'index ou en retirer puis refaire le git commit pour créer une nouvelle soumission.
1. Dauzon, Samuel (2016). « Git - Maîtrisez la gestion de vos versions ». Saint-Herblain : Editions ENI.
« Getting Started - About Version Control ». Git --fast-version-control. https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
« Git Reference ». Git --fast-version-control. https://git-scm.com/docs/
« Basic Git commands ». Atlassian Documentation. https://confluence.atlassian.com/bitbucketserver/basic-git-commands-776639767.html
« Most commonly used git tips and tricks. ». GitHub. https://github.com/git-tips/tips
« Start using Git on the command line ». GitLab. https://docs.gitlab.com/ee/gitlab-basics/start-using-git.html
« Super Userful Need To Know Git Commands ». Zack Perdue. http://zackperdue.com/tutorials/super-useful-need-to-know-git-commands
« Pro Git ». APress. https://progit2.s3.amazonaws.com/en/2016-03-22-f3531/progit-en.1084.pdf
▼Publicité
