Mode opératoire — Git et GitHub : versionner son travail d’infrastructure

Document autonome. Partie 1 théorique, parties suivantes appliquées au dossier TP - SISR/LAB. La méthode vaut pour n’importe quel projet.

Dernière mise à jour : 01/10/2026

Sommaire

1 · Pourquoi versionner de la documentation

1.1 Le problème que tout le monde connaît

   LAB/
   ├── Documentation-pfSense.md
   ├── Documentation-pfSense-v2.md
   ├── Documentation-pfSense-v2-final.md
   ├── Documentation-pfSense-v2-final-OK.md
   └── Documentation-pfSense-v2-final-OK-corrigé.md

Personne ne sait plus laquelle fait foi, ni ce qui a changé entre deux, ni pourquoi.

Git répond à trois questions que l’enregistrement classique ne sait pas traiter :

Question	Sans Git	Avec Git
Qu’est-ce qui a changé depuis hier ?	relecture intégrale	git diff
Pourquoi cette ligne existe-t-elle ?	personne ne sait	git log + message de validation
Comment revenir à l’état d’avant ?	la copie de sauvegarde, si elle existe	git restore

1.2 Ce que la synchronisation dans le nuage ne fait pas

OneDrive conserve bien un historique de versions. Mais :

La différence tient dans le mot « ensemble ». Quand tu modifies une règle de pare-feu, tu touches la matrice de flux, la documentation, le schéma et le tableau d’adressage. OneDrive enregistre quatre modifications sans lien. Git enregistre une modification qui porte sur quatre fichiers, avec son motif. Six mois plus tard, c’est toute la différence.

1.3 L’intérêt particulier pour un dossier d’infrastructure

• Les configurations sont du texte. Un haproxy.cfg, un 60-galera.cnf, un fichier de zone : Git les compare ligne à ligne. Tu vois exactement ce qui a bougé.
• La documentation suit le même rythme que l’infrastructure. Versionner les deux ensemble garantit qu’elles ne divergent pas.
• Le .drawio non compressé est du XML : il se compare lui aussi.
• La preuve de la démarche. L’historique montre la progression, les corrections, les retours en arrière. C’est bien plus convaincant qu’un dossier figé.

2 · Git ≠ GitHub

C’est la confusion qui empêche de comprendre tout le reste.

   GIT                                 GITHUB
   ───                                 ──────
   Un LOGICIEL installé sur ta         Un SERVICE en ligne qui héberge
   machine.                            des dépôts Git.

   Fonctionne sans aucun réseau.       Nécessite un compte et une connexion.

   Créé en 2005 pour le noyau Linux.   Créé en 2008. Racheté par Microsoft.

   Gratuit, libre.                     Un hébergeur parmi d'autres :
                                       GitLab, Gitea, Bitbucket, Codeberg…

Tu peux utiliser Git toute ta vie sans jamais ouvrir GitHub. L’historique vit dans le dossier caché .git, sur ton disque. GitHub n’est qu’une copie distante, utile pour trois choses : sauvegarder ailleurs, travailler à plusieurs, montrer son travail.

3 · Les trois zones

Le modèle mental sans lequel Git paraît arbitraire.

   RÉPERTOIRE DE TRAVAIL        INDEX                 DÉPÔT
   (tes fichiers)               (la zone de           (l'historique,
                                 préparation)          dans .git)

   tu modifies                  git add                git commit
   ──────────────►              ──────────────►        ──────────────►
                                                       (immuable)

Pourquoi une zone intermédiaire ? Parce qu’une session de travail touche souvent des choses sans rapport entre elles. L’index te permet de faire deux validations distinctes à partir d’une seule séance : « corrige la règle de pare-feu » d’un côté, « complète le glossaire » de l’autre. Un historique lisible vaut mieux qu’un historique exhaustif.

3.1 Les quatre états d’un fichier

git status

git status est la commande à taper en cas de doute, toujours. Elle dit où tu en es et suggère la commande suivante. La lire évite 80 % des erreurs de débutant.

4 · Les deux pièges de ce dossier

À régler avant la première commande Git. Ils ne sont pas théoriques : ils concernent précisément le dossier TP - SISR/LAB.

4.1 Piège n°1 — des secrets réels sont dans le dossier

Le sous-dossier Savegardes/ contient deux familles de fichiers qui ne doivent jamais partir sur un dépôt, même privé.

Les sauvegardes de configuration du pare-feu

Les fichiers config-*.xml contiennent :

L’export Termix

Le fichier termix-export-*.sqlite est un coffre d’identifiants. Il contient :

• 8 occurrences de PRIVATE KEY — des clés privées SSH complètes ;
• 33 occurrences de password ;
• des entrées de type credential.

Publier ce fichier revient à publier l’accès à toutes tes machines. Un dépôt privé ne suffit pas comme protection : un dépôt bascule en public par erreur, un compte se fait compromettre, un collaborateur est ajouté. La bonne règle est simple — un secret ne rentre jamais dans un dépôt, point.

La règle à retenir

Git n’oublie rien. Supprimer un fichier dans une validation ultérieure ne l’efface pas de l’historique : il reste récupérable par quiconque clone le dépôt. C’est pour cela que l’exclusion doit être posée avant la première validation, et pas après.

La solution est le fichier .gitignore, traité au §8.

4.2 Piège n°2 — Git dans un dossier synchronisé

Le dossier est dans OneDrive. Or Git et un agent de synchronisation travaillent sur les mêmes fichiers, en même temps, sans se concerter.

   Git écrit dans .git/objects      OneDrive détecte un changement
            │                                    │
            ▼                                    ▼
   opération en cours          ◄── conflit ──►  téléversement d'un fichier
                                                 à moitié écrit
            │
            ▼
   « fatal: unable to read » · index corrompu · fichiers en double

L’exclusion OneDrive ne protège pas un dossier .git — vérifié

Réflexe naturel : exclure .git dans les réglages OneDrive. Ça ne fonctionne pas, et la raison est dans le libellé de l’option elle-même :

« Tous les fichiers avec l’extension .git »

C’est un filtre par extension de nom de fichier. Or les fichiers à l’intérieur du dossier .git s’appellent config, HEAD, index, COMMIT_EDITMSG, objects/ab/cdef12… — aucun ne se termine par .git. La règle ne les intercepte pas.

Le test, avec témoin

Protocole : dans un dossier synchronisé, création au même instant d’un dossier .git contenant trois fichiers, d’un fichier archive.git (témoin positif : son extension correspond bien à la règle) et d’un note.txt (témoin négatif). On relève ensuite l’attribut ReparsePoint, qui signale un fichier fantôme OneDrive.

Le témoin positif est ce qui rend la conclusion solide. archive.git est bien exclu : la règle est donc active et fonctionnelle. Si les fichiers du dossier .git ne le sont pas, ce n’est pas un problème de configuration ni de délai — c’est que la règle filtre des extensions, pas des dossiers.

Pourquoi ReparsePoint est précisément l’état le plus défavorable

Et cela fonctionne la plupart du temps — c’est ce qui rend le problème pénible : la panne est intermittente et ne ressemble pas à sa cause.

Trois options, et une recommandation

Recommandation : l’option A. L’argument décisif n’est pas technique mais conceptuel — une fois le dépôt poussé sur GitHub, tu as déjà une copie distante. Garder par-dessus une synchronisation dans le nuage, c’est empiler deux mécanismes de sauvegarde qui se gênent, pour un bénéfice nul.

Emplacement proposé, hors de toute synchronisation :

C:\Dev\TP-SISR\

L’option B en détail

Git sait placer sa base ailleurs que dans l’arborescence de travail :

git init --separate-git-dir=/c/Dev/git-db/TP-SISR.git

Ce n’est pas un bricolage : c’est une fonction prévue de Git, utilisée notamment pour les sous-modules. La base ne peut plus être corrompue par la synchronisation, et tu conserves l’historique OneDrive sur tes documents.

Risque résiduel de l’option B. OneDrive continue de synchroniser les fichiers de travail et peut y déposer des « copie en conflit », qui apparaîtront comme non suivis dans git status. À surveiller, mais sans gravité.

Le fichier pointeur .git est lui-même exclu — vérifié par le même protocole : un fichier nommé exactement .git correspond à la règle *.git et reste local. Il ne sera donc jamais synchronisé, jamais en conflit, et ne partira pas vers un autre poste où le chemin gitdir: n’existerait pas.

L’option B est aussi la seule possible quand le chemin du dossier ne doit pas changer. Des outils peuvent être rattachés à l’arborescence par son chemin absolu : la déplacer romprait ce lien. Déplacer la seule base Git ne touche à rien.

Migrer un dépôt déjà existant

La même commande, lancée dans un dépôt qui possède déjà un dossier .git, déplace la base vers le nouvel emplacement et laisse le fichier pointeur à sa place. Rien n’est perdu :

cd /chemin/du/depot/existant
git init --separate-git-dir=/c/Dev/git-db/<nom>.git
git status      # doit afficher exactement le meme etat qu'avant

5 · Installer et configurer Git sous Windows

5.1 Installation

Git est probablement déjà présent — Git Bash est installé avec lui.

git --version

Si la commande échoue, installer depuis git-scm.com. Options par défaut sauf une : à l’écran « Configuring the line ending conversions », garder « Checkout Windows-style, commit Unix-style ».

Pourquoi cette option est importante. Windows termine ses lignes par deux caractères (CRLF), Linux par un seul (LF). Sans conversion, un fichier passé d’un système à l’autre apparaît comme entièrement modifié alors que rien n’a changé. Le réglage ci-dessus écrit en LF dans l’historique et restitue en CRLF sur ton disque : les deux mondes sont servis.

5.2 Identité

Chaque validation porte un nom et une adresse. Ils ne servent pas à t’authentifier — ils signent ton travail dans l’historique.

git config --global user.name "Axel Gouirand"
git config --global user.email "[email protected]"

5.3 Réglages recommandés

# branche principale nommée main (la convention actuelle)
git config --global init.defaultBranch main

# conversion des fins de ligne, côté Windows
git config --global core.autocrlf true

# refuse de fusionner deux historiques sans rapport : garde-fou utile
git config --global pull.rebase false

# affiche les noms de fichiers accentués correctement
git config --global core.quotepath false

# vérification
git config --global --list

core.quotepath false n’est pas cosmétique ici. Sans ce réglage, Git affiche Documentation-pfS\303\250nse.md au lieu du nom réel. Avec des fichiers nommés tableau d'adressage.xlsx et des dossiers accentués, la sortie devient illisible.

6 · S’authentifier auprès de GitHub

6.1 Le mot de passe n’existe plus

GitHub a supprimé l’authentification par mot de passe pour les opérations Git en 2021. Deux méthodes subsistent :

La clé SSH est le choix naturel ici : c’est exactement le mécanisme décrit dans le mode opératoire sur les clés SSH. Une clé privée sur ton poste, une clé publique déposée chez GitHub. Même modèle, même logique, rien de nouveau à apprendre.

6.2 Générer une clé dédiée à GitHub

Une clé par usage. Ne réutilise pas la clé qui ouvre tes serveurs : si l’une est compromise, l’autre reste valide. C’est le principe « une clé par origine ».

ssh-keygen -t ed25519 -C "github - poste Axel" -f ~/.ssh/id_github

Saisis une phrase de passe : c’est une clé humaine, elle doit en avoir une.

6.3 Déposer la clé publique chez GitHub

cat ~/.ssh/id_github.pub

Copier la ligne entière, puis sur GitHub : photo de profil → Settings → SSH and GPG keys → New SSH key · Titre : Poste Axel · Type : Authentication Key · Coller la clé.

Vérifie que tu colles bien le fichier .pub. C’est l’erreur classique : coller la clé privée. Une clé publique commence par ssh-ed25519 AAAA… et tient sur une seule ligne. Une clé privée commence par -----BEGIN OPENSSH PRIVATE KEY----- — si tu vois cela, arrête, et régénère la paire : elle est à considérer comme compromise.

6.4 Déclarer la clé à SSH

Pour que SSH utilise cette clé-là face à GitHub :

cat >> ~/.ssh/config <<'EOF'

Host github.com
    HostName     github.com
    User         git
    IdentityFile ~/.ssh/id_github
    IdentitiesOnly yes
EOF

IdentitiesOnly yes évite une erreur frustrante. Sans cette directive, SSH propose toutes tes clés l’une après l’autre. GitHub coupe la connexion après plusieurs essais infructueux, et tu obtiens un refus alors que la bonne clé était dans le lot.

6.5 Vérifier

ssh -T [email protected]

Réponse attendue :

Hi <ton-pseudo>! You've successfully authenticated,
but GitHub does not provide shell access.

« does not provide shell access » n’est pas une erreur. GitHub accepte la connexion SSH pour les opérations Git, mais refuse d’ouvrir un terminal. Ce message est le succès.

7 · Créer le dépôt

L’ordre compte : le dépôt local d’abord, avec son .gitignore, et seulement ensuite le distant. L’inverse expose à pousser un secret dès la première validation.

7.1 Préparer l’emplacement

Si tu suis l’option A du §4.2 :

mkdir -p /c/Dev/TP-SISR
cd /c/Dev/TP-SISR

Puis copier le contenu du dossier actuel — sans Savegardes/ :

SRC="/c/Users/<utilisateur>/<dossier-synchronisé>/TP - SISR/LAB"
rsync -av --exclude 'Savegardes' --exclude '.git' "$SRC/" /c/Dev/TP-SISR/

Le dossier Savegardes/ ne part pas. Il reste là où il est, dans OneDrive — c’est sa place : il contient des secrets et des sauvegardes, qui ont besoin d’être conservés mais pas versionnés.

7.2 Initialiser

cd /c/Dev/TP-SISR
git init

Git crée le dossier caché .git. Rien d’autre n’a changé : aucun fichier n’est encore suivi.

7.3 Poser le .gitignore AVANT tout

C’est l’étape à ne pas inverser. Voir le §8 pour le contenu.

7.4 Première validation

git status          # lire la liste : y a-t-il un fichier qui ne devrait pas y être ?
git add .
git status          # relire : tout est-il en vert, et rien de sensible ?
git commit -m "Dossier initial du TP : documentation, modes opératoires, livrables"

Le double git status n’est pas une précaution excessive. Le premier montre ce que Git voit, le second ce qu’il s’apprête à graver. Entre les deux, tu as une chance de repérer un fichier oublié dans l’exclusion. Après le commit, c’est trop tard.

7.5 Créer le dépôt distant

Sur GitHub : New repository.

Les trois cases doivent rester décochées. Si GitHub crée un fichier de son côté, le dépôt distant a déjà un historique — et il diverge du tien dès la première poussée. Tu obtiens alors refusing to merge unrelated histories, un message déroutant pour une cause aussi banale.

7.6 Relier et pousser

git remote add origin [email protected]:<ton-pseudo>/tp-sisr-infrastructure.git
git branch -M main
git push -u origin main

Validation

git remote -v
git log --oneline

Puis rafraîchis la page GitHub : tes fichiers doivent y être, et Savegardes/ ne doit pas y figurer.

8 · Le .gitignore de ce dossier

À créer à la racine, avant la première validation.

cat > .gitignore <<'EOF'
# ============================================================
#  SECRETS — ne doivent JAMAIS être versionnés
# ============================================================
Savegardes/
*.sqlite
config-*.xml
*.pem
*.key
id_*
!id_*.pub

# ============================================================
#  FICHIERS GÉNÉRÉS — reproductibles depuis les sources
# ============================================================
*.pdf
_part*.html
_gen*.html
_a.html
_b.html
_c.html
_d.html
_verif.*
_chk.js
_test.js

# ============================================================
#  ARTEFACTS WINDOWS ET BUREAUTIQUE
# ============================================================
Thumbs.db
desktop.ini
~$*
*.tmp

# ============================================================
#  OUTILS
# ============================================================
node_modules/
EOF

8.1 Chaque bloc, et pourquoi

8.2 Un .gitignore n’agit que sur ce qui n’est pas déjà suivi

Si un fichier a déjà été validé une fois, l’ajouter au .gitignore ne le retire pas. Git continue de le suivre.

Pour cesser de suivre un fichier déjà validé — sans le supprimer du disque :

git rm --cached chemin/du/fichier
git commit -m "Retire <fichier> du suivi : contient des données sensibles"

Cela ne l’efface pas de l’historique passé. Le fichier reste consultable dans les validations antérieures. S’il contenait un secret, voir le §13 — et la première chose à faire n’est pas de nettoyer l’historique.

8.3 Vérifier avant de valider

# liste ce qui SERAIT ajouté, sans rien faire
git add --dry-run .

# vérifie qu'un fichier précis est bien exclu, et par quelle règle
git check-ignore -v "Savegardes/termix-export-sio2527.sqlite"

git check-ignore -v donne la règle qui s’applique, avec son numéro de ligne. C’est l’outil pour comprendre pourquoi un fichier passe — ou ne passe pas — au travers.

9 · Le cycle de travail quotidien

9.1 Le cycle minimal

   ┌──► tu travailles (édition des fichiers)
   │          │
   │          ▼
   │    git status          où en suis-je ?
   │          │
   │          ▼
   │    git add <fichiers>  je choisis ce qui part ensemble
   │          │
   │          ▼
   │    git commit -m "…"   je grave, avec le motif
   │          │
   │          ▼
   └──  git push            j'envoie sur GitHub

9.2 Les commandes de tous les jours

git status                       # état courant — en cas de doute, toujours celle-ci
git diff                         # ce qui a changé et n'est pas préparé
git diff --staged                # ce qui est préparé et sera validé
git add Matrice-de-flux.md       # préparer un fichier précis
git add .                        # tout préparer
git commit -m "message"          # valider
git log --oneline --graph -10    # les 10 dernières validations
git push                         # envoyer

9.3 Écrire un message de validation utile

Le message s’adresse à toi dans six mois. Il doit répondre à « pourquoi », pas à « quoi » — le « quoi » est déjà dans le diff.

Forme conseillée — une ligne courte à l’impératif, et si besoin un paragraphe après une ligne vide :

git commit -m "Passe le contrôleur de domaine en Server Core" -m \
"Une installation graphique ne se convertit pas en Core depuis Server 2016.
La VM est donc recréée. L'adresse 10.0.30.10 est conservée, seul le contenu
de l'alias DC_AD change."

9.4 Valider par intention, pas par séance

Tu as modifié la matrice de flux et complété le glossaire. Ce sont deux sujets :

git add Matrice-de-flux.md Documentation-pfSense.md
git commit -m "Resserre la règle WEB 3 sur le répartiteur seul"

git add MO-5-Git-GitHub.md
git commit -m "Ajoute le mode opératoire Git et GitHub"

git push

Deux validations valent mieux qu’une. Si la première se révèle fausse, tu l’annules sans perdre la seconde. C’est la raison d’être de l’index.

10 · Fichiers binaires et fichiers générés

10.1 Ce que Git fait d’un fichier binaire

Git stocke une copie complète de chaque version d’un fichier binaire. Il ne sait pas enregistrer « seulement ce qui a changé » dans un PDF ou un classeur.

   Fichier texte (.md)              Fichier binaire (.pdf)
   v1 : 2 000 lignes                v1 : 3 Mo
   v2 : +3 lignes                   v2 : 3 Mo   (copie entière)
   v3 : −1 ligne                    v3 : 3 Mo   (copie entière)
   ───────────────                  ────────────────────────
   stocké : ~2 000 lignes           stocké : 9 Mo

10.2 Classement des fichiers de ce dossier

La règle générale : versionner la source, pas le produit. Un PDF se régénère en une commande à partir de son HTML. Le stocker, c’est accumuler des mégaoctets pour une information déjà présente.

10.3 Comment livrer les PDF sans les versionner

Deux voies :

10.4 Si tu préfères malgré tout versionner les PDF

C’est défendable pour un dossier qui doit être consultable sans outillage. Retire alors *.pdf du .gitignore, mais limite les régénérations inutiles : ne reconstruis le PDF que lorsque tu t’apprêtes à le remettre, pas à chaque retouche du HTML.

Ordre de grandeur à garder en tête. Quatre PDF d’environ 1,5 Mo régénérés vingt fois font 120 Mo d’historique — pour quatre fichiers. GitHub accepte, mais le dépôt devient lent à cloner et l’historique illisible.

11 · Marquer les versions de livrables

Une étiquette (tag) nomme une validation précise. C’est le mécanisme adapté à « la version remise le 1er octobre ».

git tag -a v1.0 -m "Dossier remis : infrastructure HA validée, 4 tests restants"
git push origin v1.0

git tag                    # lister les étiquettes
git show v1.0              # ce que contenait cette version
git checkout v1.0          # revenir voir l'état d'alors (lecture seule)
git switch -                # revenir au présent

L’étiquette répond à « quel était l’état exact du dossier le jour de la remise ? » Sans elle, il faut retrouver la bonne validation à la date — faisable, mais fastidieux.

11.1 Les publications GitHub

Sur GitHub, une étiquette peut devenir une publication (release) à laquelle on attache des fichiers.

C’est la réponse propre au problème du §10 :

   Le dépôt contient    →  les sources (HTML, Markdown, schémas)
   La publication v1.0  →  les PDF générés, attachés à l'étiquette

GitHub → onglet Releases → Draft a new release → choisir l’étiquette → glisser les PDF dans la zone de dépôt.

L’historique reste léger, et les documents remis restent accessibles à leur version exacte. C’est exactement ce que fait un projet logiciel avec ses binaires compilés.

12 · Réparer

La raison pour laquelle on utilise Git : presque tout est réversible.

12.1 Annuler une modification non validée

# un fichier précis — ATTENTION : les modifications sont PERDUES
git restore Matrice-de-flux.md

# tout le répertoire de travail
git restore .

C’est la seule opération vraiment destructrice de ce chapitre. Ce qui n’a jamais été validé n’existe nulle part ailleurs : Git ne peut pas le restituer.

12.2 Retirer un fichier de l’index, sans perdre les modifications

git restore --staged fichier.md

12.3 Corriger la dernière validation

# modifier seulement le message
git commit --amend -m "Message corrigé"

# ajouter un fichier oublié à la dernière validation
git add fichier-oublie.md
git commit --amend --no-edit

Uniquement si la validation n’a pas été poussée. --amend remplace la validation par une nouvelle, avec un identifiant différent. Si l’ancienne est déjà sur GitHub, les deux historiques divergent.

12.4 Annuler une validation déjà poussée

git revert <identifiant>

revert n’efface pas : il ajoute une validation qui fait l’inverse. L’historique reste intact et honnête — on voit l’erreur et sa correction. C’est la méthode à employer dès que le travail est partagé.

12.5 Retrouver une validation perdue

git reflog

reflog est le filet de sécurité que peu de gens connaissent. Il consigne tous les déplacements de ta branche, y compris ceux effacés par un reset. Tant que les objets n’ont pas été nettoyés — plusieurs semaines — presque rien n’est définitivement perdu.

git reset --hard <identifiant-retrouvé>

12.6 Comparer deux états

git diff HEAD~3 HEAD -- Documentation-pfSense.md    # 3 validations en arrière
git diff v1.0 HEAD                                   # depuis la remise
git log -p -- Matrice-de-flux.md                     # l'histoire d'un fichier

13 · Un secret est parti sur GitHub

Cela arrive. La réaction ordinaire est de supprimer le fichier et de pousser — c’est insuffisant, et ce n’est pas la priorité.

13.1 L’ordre des opérations

① Considère le secret comme compromis, et change-le. MAINTENANT.

C’est la seule action qui compte réellement. Tout le reste est du nettoyage. Un dépôt public est indexé en quelques minutes ; des robots scrutent les validations en continu. Même sur un dépôt privé, tu ne sais pas qui a cloné.

② Ensuite seulement, nettoyer l’historique :

# outil dédié, à installer : pip install git-filter-repo
git filter-repo --path Savegardes/ --invert-paths
git push --force --all
git push --force --tags

③ Prévenir toute personne ayant cloné le dépôt : sa copie contient encore le secret.

13.2 Pourquoi la suppression simple ne suffit pas

   Validation 12 :  ajout de config.xml        ◄── le secret est ICI
   Validation 13 :  … autre travail
   Validation 14 :  suppression de config.xml  ◄── le fichier disparaît du présent

   git show <validation-12>:config.xml         ◄── et il ressort intact

Git est conçu pour ne rien perdre. C’est sa qualité première, et c’est exactement ce qui en fait un mauvais endroit pour un secret. La seule protection fiable est de ne jamais l’y mettre — d’où le .gitignore posé avant la première validation.

14 · Dépôt privé ou public

14.1 Pour ce dépôt-ci : privé

Le registre des dettes est l’élément le plus sensible du dossier. C’est une liste argumentée de ce qui n’est pas protégé. Excellente pratique d’ingénierie — à ne pas publier.

14.2 L’usage portfolio

Un dépôt public bien tenu est un atout réel pour un dossier de candidature. Mais ce n’est pas le même dépôt :

Tes quatre modes opératoires se publient très bien. Ils sont génériques, pédagogiques et ne révèlent rien — à condition de substituer les adresses. C’est un contenu qui se défend en entretien bien mieux qu’un dépôt de configurations.

14.3 Changer la visibilité

Settings → General → tout en bas, Danger Zone → Change repository visibility.

Passer de privé à public ne se répare pas. Dès la bascule, le dépôt est clonable et indexable, historique compris. Relire git log --stat avant, pas après.

15 · Pièges et checklists

15.1 Les pièges classiques

15.2 Checklist — mise en place initiale

• Git installé, git --version répond
• Identité configurée (user.name, user.email)
• core.autocrlf et core.quotepath réglés
• Clé SSH dédiée à GitHub générée, avec phrase de passe
• Clé publique déposée chez GitHub
• ~/.ssh/config complété avec IdentitiesOnly yes
• ssh -T [email protected] répond Hi <pseudo>!
• Dépôt placé hors du dossier synchronisé
• .gitignore écrit AVANT la première validation
• git add --dry-run . relu ligne à ligne
• git check-ignore -v vérifié sur les fichiers sensibles
• Première validation faite
• Dépôt distant créé vide et en privé
• Première poussée réussie
• Page GitHub contrôlée : Savegardes/ absent

15.3 Checklist — avant chaque poussée

• git status : rien d’inattendu
• git diff --staged : c’est bien ce que je veux graver
• Aucun mot de passe, clé ou export d’identifiants dans le lot
• Le message explique pourquoi, pas seulement quoi
• Une validation = une intention

15.4 Checklist — avant de rendre publique une version

• git log --stat relu intégralement
• Aucun secret dans l’historique, pas seulement dans l’état courant
• Adresses réelles substituées
• Captures d’écran revues une par une
• Registre des dettes retiré
• Étiquette posée et publication créée avec les documents remis

Le réflexe à garder. Avant chaque git add, une seconde question : « si ce dépôt devenait public demain, est-ce que ce fichier me poserait un problème ? » Si la réponse n’est pas un non immédiat, il va dans le .gitignore.