Dans les étapes suivantes, vous continuerez à travailler en pair-programming.

1. .gitignore

Durant le TP, certains scripts de vérification seront mis à disposition. Il ne faut surtout pas les commiter dans le repository. Pour cela, il faut les ignorer.

📋️ Instructions

Créez la branche init-gitignore.
Créez le fichier .gitignore à la racine du dépôt.
Ajoutez-y la ligne bin/assert/ afin d’ignorer le dossier bin/assert et tout son contenu.
Ajoutez le fichier .gitignore à l’index : git add .gitignore.
Vérifiez l’état des fichiers locaux avec git status.
- Si le fichier bin/assert/01-env est listé, c’est qu’il a été ajouté par erreur.
  Supprimez-le de l’index avec git restore --staged bin/assert/01-env.
- Normalement, il ne devrait y avoir que le fichier .gitignore listé.
Commitez le fichier : git commit -m "🙈 Initial commit".
Pushez la branche sur le dépôt distant : git push origin init-gitignore.
Sur GitHub, créez la PR pour merger la branche init-gitignore sur la branche main.
Le reste du groupe peut faire la revue de la PR et une fois approuvée, la merger.

🧹 Remise à niveau

Vérifiez bien que la branche init-gitignore a été supprimée du GitHub après la PR.

Ensuite, il faut synchroniser le repository local.

Pour la personne ayant fait la PR

git switch main
git pull
git branch -D init-gitignore

Pour les autres personnes

git switch main
git pull

2. README.md

Le fichier README est le “point d’entrée” d’un repository ; il est affiché sur la page principale du repository sur GitHub ou GitLab et est généralement le fichier ouvert par défaut dans l’IDE.

Ce fichier décrit le projet, son but, son fonctionnement et les diverses instructions pour le mettre en place ou l’utiliser.

Dans le cadre de ce TP, il servira à décrire le TP, les contributeurs (membres du groupe), les tâches (et si elles ont été réalisées), ainsi que vos retours d’expérience.

📋️ Instructions

Créez la branche init-readme.
Créez le fichier README.md à la racine du dépôt, s’il n’a pas déjà été initialisé sur GitHub.
Récupérez le contenu défini ci-dessous en le remplissant avec les informations demandées.
Vérifiez qu’il ne reste aucun commentaire ou instruction dans le fichier.
Ajoutez le fichier README.md à l’index : git add README.md.
Commitez le fichier : git commit -m "👓️ Initial commit".
Pushez la branche sur le dépôt distant et créez la PR correspondante.
Pensez à la revue, à l’approbation, au merge, puis à la « 🧹 remise à niveau », telle qu’elle était présentée dans la tâche précédente.

📝 Contenu du README.md

Récupérez le contenu suivant en le remplissant avec les informations demandées.

Note : Ce qui est indiqué entre chevrons doit être intégralement remplacé par la valeur demandée.
Par exemple, <NOM Prénom> sera remplacé par VILLENA Billy, dans mon cas.

Note² : Les lignes indiquées de cette manière : [//]: # (texte) font office de commentaires. Ce sont des instructions ou des remarques pour vous aider à remplir le contenu du fichier.
Elles ne doivent pas être présentes dans le fichier final.

# 3OLEN "2024-2025" - <Nom du groupe> - TP Git

[//]: # (Courte description du TP)

## 🎯 Objectifs

[//]: # (Liste des objectifs définis sur la page du cours.)
[//]: # (Veuillez à bien utiliser la syntaxe de liste Markdown ainsi que les différentes règles de formatage)

## 📚️ Ressources utiles

- [🔗 Sujet de TP](https://3olen.github.io/cours-initiaux/git/tp/1)
- [🔗 Cours 30 octobre](https://3olen.github.io/git/30-octobre)
[//]: # (Éventuellement d'autres liens ou ressources utiles pour la réalisation de ce TP si vous en avez l'utilité)

## 👥 Contributeurs

[//]: # (Pour chaque étudiant du groupe ⚠️ dans l'ordre alphabétique des noms de famille :)
- [<NOM Prénom>](<Lien vers le profil GitHub>)
[//]: # "Faites attention à bien garder la syntaxe des liens : `[texte affiché](lien hypertexte)`"

## 📋️ Instructions du projet

*Rien pour l'instant...*
[//]: # (Tout ce qui permettra de mettre en place le projet en local sera indiqué ici)

## 📝 Tâches

- [x] **.gitignore** : Initialisation du `.gitignore`.
- [x] **README.md** : Initialisation du `README.md`.
- [ ] **.editorconfig** : Initialisation du `.editorconfig`.
- [ ] **Hooks** : N'autoriser qu'un commit par branche.
[//]: # (En prenant exemple sur les deux premières lignes de la liste, faites de même pour les autres tâches)
[//]: # (La syntaxe `- [ ]` permet de définir une liste à cocher ; parfait pour un todo-list)
[//]: # (La syntaxe `- [x]` permet de cocher la case et donc définir la tâche comme terminée)

## 🐕‍🦺 Retours d'expérience

### <NOM Prénom du contributeur 1>

*__TODO__: Retours d'expérience de l'étudiant.*

[//]: # (Faire de même pour chaque membre du groupe)

3. .editorconfig

Afin de contribuer à l’homogénéité des fichiers textes, les IDE et certains éditeurs de texte (par le biais de plugins) prennent en charge les spécifications EditorConfig par le biais du fichier .editorconfig.

On y trouve des règles de formatage basiques : indentation, encodage, taille et fin de ligne, etc.

Il s’agit d’un très bon ajout à notre TP et pour n’importe quel projet.

Pour en savoir plus : 🔗 EditorConfig.

📋️ Instructions

Créez la branche init-editorconfig.
Créez le fichier .editorconfig à la racine du dépôt.
Ajoutez le contenu défini ci-après dans le fichier.
Ajoutez le fichier .editorconfig à l’index : git add .editorconfig.
Modifiez le README.md pour cocher la tâche correspondante, puis ajoutez ce fichier à l’index.
Commitez les changements : git commit -m "🐁 Initial commit".
Pushez la branche sur le dépôt distant et créez la PR correspondante.
Pensez à la revue, à l’approbation, au merge, puis à la « 🧹 remise à niveau ».

📝 Contenu du .editorconfig

root = true

[*]
charset = utf-8
end_of_line = lf
indent_size = 4
indent_style = space
insert_final_newline = true
tab_width = 4
trim_trailing_whitespace = true

[*.md]
max_line_length = 120

4. Hooks

Les hooks sont des scripts exécutés par Git lors de certains événements (avant un commit par exemple). Ils permettent d’automatiser des tâches et de vérifier la qualité du travail avant de le commiter.

Point de vue personnel
Utilisez des hooks pour vérifier seulement, et rejeter l’action si les conditions ne sont pas remplies.
Ne les utilisez pas pour réaliser des actions automatiques sur le travail réalisé (formatage de code par exemple). C’est à chaque membre de l’équipe de prendre la responsabilité de son travail et de le faire correctement. Et c’est à chacun de “s’éduquer” sur les règles mises en place à respecter.
Par ailleurs, vous pourriez avoir des surprises avec des modifications automatiques d’un script ou d’un linter.

Nous allons mettre en place un hook qui va vérifier que la branche locale ne définit qu’un seul commit.

Dans les bonnes pratiques des branches, il n’est jamais nécessaire de définir plusieurs commits sur une même branche, puisque chaque branche doit représenter une tâche aussi petite et épurée que possible. Si ce n’est pas le cas, c’est que la branche (et sa tâche associée) n’a sûrement pas été correctement découpée.

📋️ Instructions

Créez la branche init-hooks.
Créez le dossier bin/hooks depuis la racine du repository.
Récupérez le fichier : hook-pre-commit-01.
Déplacez-le dans le dossier bin/hooks de votre dépôt et renommez-le pre-commit.
Assurez-vous qu’il est bien exécutable avec les commandes appropriées.
Copiez-le dans le dossier .git/hooks de votre repository.
C’est de cette manière que votre Git local va pouvoir le prendre en considération et l’exécuter.
Ajoutez le fichier bin/hooks/pre-commit à l’index et commitez-le : git commit -m "🔨 [hooks] One commit per branch".
Normalement, le hook a été exécuté et le commit a été accepté.
Modifiez le README.md pour cocher la tâche correspondante, puis ajoutez ce fichier à l’index.
Tentez d’effectuer un nouveau commit : git commit -m "👓️ [Hooks] done".
Normalement, le hook a été exécuté et le commit a été rejeté : Vous avez déjà un commit défini [...].
Amendez donc le commit précédent, sans modifier le message : git commit --amend --no-edit.
Cette fois, le commit a été accepté.

Pour mener cette vérification jusqu’au bout, on peut faire un hook avant le push.

Récupérez le fichier : hook-pre-push-01.
Déplacez-le dans le dossier bin/hooks de votre dépôt et renommez-le pre-push.
Assurez-vous qu’il est bien exécutable avec les commandes appropriées.
Copiez-le dans le dossier .git/hooks de votre repository.
Ajoutez le fichier bin/hooks/pre-push à l’index et commitez-le : git commit --no-verify -m "🔨 [hooks] Do not push several commits".
L’option --no-verify permet de by-passer l’exécution du pre-commit hook.
Tentez de pusher la branche avec ses deux commits.
Normalement, le hook a été exécuté et le push a été rejeté : Vous avez plusieurs commits. [...].
Exécutez alors le rebase interactif comme demandé : git rebase -i HEAD~2.
- Dans l’éditeur de texte fourni, remplacez le mot-clé pick par squash (ou s) pour le second commit.
- Sauvegardez et fermez l’éditeur (si éditeur de base : Ctrl + x, puis o et enfin Entrée).
- L’éditeur de texte s’ouvre à nouveau pour définir le nouveau message de commit. Gardez le message du premier commit.
Faites de nouveau un push qui devrait être accepté et effectif.
Vous connaissez la chanson : PR / revue / approbation / Merge / 🧹 remise à niveau.

Et maintenant ?

Vous avez pu manipuler la majorité des éléments de base d’un projet Git tout en effectuant quelques commits et pushs.

Nous en avons profité pour rappeler quelques outils avancés utilisés pour garantir un historique “léger” : le commit --amend et le squash par le biais du rebase interactif.

Et vous avez découvert les hooks et une possible utilisation. Il y a cependant quelque chose d’incomplet avec ces hooks ; on les a versionnés dans le dossier bin/hooks, mais ils ne sont pas pris en compte par Git. Il faut les copier dans le dossier .git/hooks.

Comment garantir que chaque membre du groupe a installé les hooks ? Et comment garantir que les hooks sont toujours maintenus à jour dans chaque environnement local ?

C’est le sujet de la partie suivante !