Garder le dépôt propre

Ce que vous saurez faire

Gardez les mots de passe, les clés et les gros fichiers générés hors de votre dépôt. Un fichier que vous ajoutez par un commit (enregistrement des changements) reste dans l’historique. Chaque personne qui clone le dépôt en reçoit une copie.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 30 minutes

Ce que vous devez savoir

• Comment git push et git pull fonctionnent avec la branche de suivi, selon Synchroniser de façon réfléchie : votre copie du dépôt distant.
• Comment préparer un changement et faire un commit, selon Suivre une première modification : trois endroits pour vos modifications.

Ce qu’il vous faut sur votre ordinateur

• Le dépôt ~/projects/ticket-notes, sur la branche main. git status affiche working tree clean (répertoire de travail propre). Si vous êtes sur une autre branche, exécutez git switch main.

• Le dépôt distant origin, qui est le dossier ~/projects/team-remote.git. Vous l’avez créé dans Synchroniser de façon réfléchie : créer un dépôt distant d’exercice. Vous y avez poussé main dans Synchroniser de façon réfléchie : exercice guidé : jouer les deux rôles. L’exercice guidé de cette leçon y pousse de nouveau des changements.

• Si git remote -v n’affiche rien, refaites Créer un dépôt distant d’exercice. Ensuite, exécutez git push -u origin main.

• Si le dépôt manque ou ne fonctionne plus, un script peut recréer l’état de départ de cette leçon. Dans ~/projects, exécutez :

  git clone https://github.com/Nextia-Intelligence/nextia-learning-labs.git
  sh nextia-learning-labs/C14/setup.sh m02-l03 --reset

  Exécutez la commande git clone une seule fois. Si vous avez déjà le dossier nextia-learning-labs, exécutez plutôt git -C nextia-learning-labs pull. Les étapes d’une demande de tirage : préparer le laboratoire d’exercice explique le script en détail. Le script crée ticket-notes, team-remote.git et sam-notes dans ~/projects/c14-lab. C’est l’état atteint à la fin de Synchroniser de façon réfléchie : exercice guidé : jouer les deux rôles. Le commit Add ticket 102 (ajouter le billet 102) de Sam a une empreinte différente de celle de la leçon (1d45995). C’est parce que, dans la leçon, vous avez fait ce commit vous-même. C’est normal. Utilisez ensuite ~/projects/c14-lab au lieu de ~/projects dans cette leçon. --reset supprime d’abord un ancien dossier c14-lab, mais votre dossier ~/projects/ticket-notes ne change pas.

L’historique garde tout

Git garde chaque version de chaque fichier ajouté par un commit. Si vous supprimez un fichier dans un nouveau commit, les anciens commits le contiennent encore. Amira a ajouté un fichier de paramètres par un commit, puis l’a supprimé dans le suivant. Une commande permet encore d’afficher l’ancien contenu :

Terminal

git show c9a1952:settings.local

Sortie

DEBUG=true

c9a1952:settings.local signifie « le fichier settings.local tel qu’il était dans le commit c9a1952 ». Quand vous poussez vos changements, le dépôt distant reçoit tout l’historique. Chaque personne qui le clone le reçoit aussi.

Il est donc beaucoup plus facile de garder un fichier hors de Git que de l’en retirer plus tard. Trois types de fichiers doivent rester exclus :

Type de fichier	Exemples	Pourquoi l’exclure
Secrets	.env, clés d’API, mots de passe, clés privées	Toute personne qui peut lire le dépôt peut les utiliser.
Fichiers créés par les outils	exports/, *.log, .venv/, node_modules/, __pycache__/	Vous pouvez les recréer. Ils changent souvent et rendent les différences difficiles à lire.
Gros fichiers	jeux de données, modèles entraînés, archives .zip, vidéos	Chaque clonage télécharge toutes les versions. GitHub refuse les fichiers de plus de 100 Mo.

.gitignore : indiquer à Git quoi exclure

Un fichier .gitignore contient une liste de motifs, un par ligne. Git n’affiche pas les fichiers non suivis qui correspondent à ces motifs dans git status. La commande git add ne les ajoute pas à la zone de préparation. Vous ajoutez .gitignore lui-même par un commit, pour que toute l’équipe utilise les mêmes règles.

Motif	Correspond à
.env	Un fichier ou un dossier nommé .env, dans n’importe quel dossier.
exports/	Un dossier nommé exports et tout son contenu. Le / à la fin signifie « un dossier seulement ».
*.log	Chaque fichier dont le nom se termine par .log. * signifie « n’importe quel texte ».
# text	Un commentaire. Git ignore la ligne.

Exemple détaillé : ignorer une clé, une exportation et un journal

L’outil de billets d’Amira a besoin d’une clé. Elle la garde donc dans un fichier nommé .env. L’outil crée aussi exports/tickets-2026.zip et sync.log. La commande git status --short indique que les trois fichiers ne sont pas suivis :

git status --short

?? .env
?? exports/
?? sync.log

Attention

Dans ce cours, utilisez une fausse valeur dans .env, par exemple TICKETS_API_KEY=example-not-a-real-key. Ne mettez jamais une vraie clé dans un dépôt d’exercice.

Elle crée .gitignore dans le dossier racine du dépôt :

.gitignore

# Secrets: never commit them
.env

# Files that tools make
exports/
*.log

Maintenant, git status --short affiche seulement le nouveau fichier .gitignore :

git status --short

?? .gitignore

Pour vérifier quelle règle correspond à un fichier, elle utilise git check-ignore -v. La sortie affiche le fichier, le numéro de ligne et le motif :

Terminal

git check-ignore -v .env exports/tickets-2026.zip sync.log

Sortie

.gitignore:2:.env  .env
.gitignore:5:exports/  exports/tickets-2026.zip
.gitignore:6:*.log  sync.log

Si quelqu’un essaie d’ajouter un fichier ignoré à la zone de préparation, Git refuse :

Terminal

git add .env

Sortie

The following paths are ignored by one of your .gitignore files:
.env
hint: Use -f if you really want to add them.

N’utilisez pas -f pour un secret. Amira fait un commit de .gitignore :

Terminal

git add .gitignore
git commit -m "Ignore secrets, exports and logs"

Exemple détaillé : un fichier que Git suit déjà

.gitignore touche seulement les fichiers non suivis. Si vous avez ajouté un fichier par un commit avant d’ajouter sa règle, Git continue de le suivre.

Amira a ajouté settings.local par un commit, puis a ajouté settings.local à .gitignore et modifié le fichier. Git affiche encore le changement :

git status --short

 M .gitignore
 M settings.local

Pour arrêter de suivre le fichier tout en le gardant sur son ordinateur, elle utilise git rm --cached. L’option --cached signifie « retirer seulement de la zone de préparation ». Sans --cached, git rm supprime aussi le fichier du dossier.

Terminal

git rm --cached settings.local
git status --short

Sortie

rm 'settings.local'
 M .gitignore
D  settings.local

Le D (suppression) dans la première colonne signifie que le prochain commit retirera le fichier du dépôt. Elle ajoute aussi .gitignore à la zone de préparation, puis fait un commit des deux changements :

Terminal

git add .gitignore
git commit -m "Stop tracking settings.local"

settings.local est encore dans son dossier, et Git l’ignore maintenant. Mais l’ancien commit c9a1952 le contient encore. C’est acceptable pour un paramètre de débogage. Pour un secret, ce ne l’est pas : consultez l’erreur fréquente ci-dessous.

Petits commits

Un dépôt propre contient aussi des commits clairs. Une personne qui révise un commit le lit pour comprendre un changement. Si un commit mélange trois changements, cette personne doit les séparer mentalement.

• Un objectif par commit. « Ajouter des niveaux de priorité » est un seul objectif. « Ajouter des niveaux de priorité, corriger une faute et mettre à jour les contacts » correspond à trois commits.
• Vérifiez avant de faire un commit. Exécutez git diff --staged et lisez chaque ligne. Cherchez les fichiers que vous ne vouliez pas ajouter.
• Écrivez le message comme une instruction. « Ajouter le billet 104 », pas « Ajout de trucs ». Expliquez pourquoi dans un deuxième paragraphe si le changement ne rend pas la raison évidente.

Exercice guidé : ignorer vos propres fichiers

1. Dans ~/projects/ticket-notes, créez trois fichiers que Git ne doit pas suivre. Utilisez votre éditeur ou exécutez ces commandes :

   echo "TICKETS_API_KEY=example-not-a-real-key" > .env
   mkdir exports
   echo "export" > exports/tickets.csv
   echo "sync started" > sync.log

   echo "text" > file écrit le texte dans un nouveau fichier.

2. Exécutez git status --short. Les trois fichiers affichent ?? (non suivi).

3. Créez .gitignore avec les cinq lignes de l’exemple détaillé. Enregistrez-le.

4. Exécutez git status --short. Seul ?? .gitignore apparaît.

5. Vérifiez les règles :

   git check-ignore -v .env exports/tickets.csv sync.log

   Chaque fichier affiche la ligne de .gitignore qui lui correspond.

6. Faites un commit de .gitignore, puis poussez-le pour que votre équipe reçoive les mêmes règles :

   git add .gitignore
   git commit -m "Ignore secrets, exports and logs"
   git push

À vous de jouer : règles pour un projet Python

Votre équipe ajoute Python à l’outil de billets. Le dossier contient maintenant ces nouveaux éléments :

• .venv/ : un environnement Python de 400 Mo.
• data/raw/tickets-full.csv : une exportation de vrais billets de 2 Go.
• data/sample.csv : 20 billets fictifs pour les tests. L’équipe veut ce fichier dans Git.
• __pycache__/ : des fichiers créés par Python.

Ajoutez des règles à .gitignore pour que Git ignore tout sauf data/sample.csv. Créez les fichiers et les dossiers, puis démontrez que vos règles fonctionnent avec git status --short et git check-ignore -v.

Afficher une réponse possible

.gitignore (new lines)

# Python
.venv/
__pycache__/

# Large or private data
data/raw/

La commande git status --short affiche alors M .gitignore (modifié) et ?? data/. data/ apparaît parce que data/sample.csv n’est ni suivi ni ignoré. La commande git check-ignore -v data/sample.csv n’affiche rien. Cela signifie qu’aucune règle ne l’ignore. Il y a une deuxième raison d’exclure data/raw/ : les vrais billets peuvent contenir des données personnelles.

Erreur courante

J'ai ajouté un secret par un commit

Symptôme : git log --stat ou une révision montre .env, une clé ou un mot de passe dans un commit.

Cause : le fichier a été ajouté à la zone de préparation avant la création d’une règle .gitignore. Ou quelqu’un a utilisé git add -f.

Solution : agissez dans cet ordre.

1. Considérez le secret comme public. Si vous avez poussé le commit, d’autres personnes et services peuvent en avoir une copie. Allez au service qui a fourni la clé et révoquez-la ou créez-en une nouvelle. Faites cela en premier. C’est la seule étape qui empêche une utilisation abusive.
2. Arrêtez de suivre le fichier avec git rm --cached .env, ajoutez .env à .gitignore, puis faites un commit.
3. Dites à votre équipe ce qui s’est passé et quelle clé vous avez remplacée.

L’ancien commit contient encore le secret. Il est possible de le retirer de l’historique, mais cela réécrit l’historique partagé. Chaque clone doit alors être remplacé. Cela n’aide pas non plus si quelqu’un a déjà copié la clé. C’est pourquoi l’étape 1 est la plus importante.

Vérifiez votre compréhension

Amira ajoute config.json par un commit. Ce fichier contient un mot de passe. Elle ajoute ensuite config.json à .gitignore et fait un autre commit. Le mot de passe est-il maintenant protégé?

Afficher la réponse

Non, pour deux raisons. D’abord, .gitignore ne touche pas un fichier que Git suit déjà. Git suit donc encore config.json. Elle doit aussi utiliser git rm --cached config.json. Ensuite, le premier commit contient encore le mot de passe. Si elle l’a poussé, elle doit changer le mot de passe.

Vérifiez votre compréhension

Vérification pratique : démontrez que .env est ignoré dans votre dépôt et indiquez la règle qui l'ignore.

Afficher la réponse

Exécutez git check-ignore -v .env. La sortie affiche .gitignore, le numéro de ligne et le motif, par exemple .gitignore:2:.env .env. Si la sortie est vide, aucune règle ne correspond au fichier. Exécutez aussi git status --short : .env ne doit pas apparaître.

Récapitulatif

• Git garde chaque version ajoutée par un commit. Supprimer un fichier plus tard ne le retire pas de l’historique.
• .gitignore exclut les fichiers non suivis de git status et de git add. Ajoutez-le par un commit pour que toute l’équipe l’utilise.
• Utilisez git check-ignore -v pour voir quelle règle ignore un fichier.
• git rm --cached arrête de suivre un fichier et le garde dans votre dossier.
• Si vous ajoutez un secret par un commit, remplacez-le d’abord. Arrêtez ensuite de suivre le fichier.
• Limitez chaque commit à un changement clair et lisez git diff --staged avant de faire le commit.

C’est la fin du module 2. Dans le module 3, vous combinez ces compétences dans une demande de tirage (pull request). Votre équipe révise votre branche avant son intégration à main.

Leçon suivante : Les étapes d'une demande de tirage