🔄 Git & Workflow DevOps : Versionner son infrastructure

Ce que j’ai fait

1. C’est quoi Git et pourquoi j’en ai besoin ?

Mon infrastructure fonctionne. Mais imaginons que je modifie un fichier de config et que tout casse. Comment je reviens en arrière ? Comment je me souviens de ce que j’ai changé il y a 2 semaines ?

Git, c’est un système qui prend une « photo » de mon projet à chaque fois que je le lui demande. Chaque photo s’appelle un commit. Je peux :

• Voir l’historique complet de toutes mes modifications
• Revenir à n’importe quelle version précédente
• Sauvegarder mon travail sur GitHub (un coffre-fort en ligne)

GitHub, c’est aussi la vitrine de mon projet. Les gens pourront voir mon code, mon historique, et comprendre comment j’ai travaillé.

2. Créer le dépôt GitHub

Un dépôt (ou « repo »), c’est simplement un dossier de projet hébergé sur GitHub.

Sur le navigateur :

1. Créer un compte sur github.com
2. Cliquer sur « New repository »
3. Nom : portfolio-infra
4. Visibilité : Public (pour que les gens puissent le voir)
5. Ne rien cocher d’autre → Create repository

Ensuite, créer un token d’authentification (PAT) :

GitHub n’accepte plus les mots de passe classiques pour envoyer du code. Il faut un token, une sorte de mot de passe spécial à usage unique.

1. GitHub → Settings → Developer Settings → Personal Access Tokens → Tokens (classic)
2. Générer un nouveau token avec la permission repo
3. Copier le token et le stocker immédiatement dans un espace sécurisé

3. Initialiser Git sur le serveur

Maintenant je relie mon dossier de projet sur le serveur à mon dépôt GitHub.

cd /srv/portfolio

# Transformer ce dossier en projet Git
git init

# Dire à Git qui je suis (pour signer les commits)
git config --global user.name "MonPseudoGitHub"
git config --global user.email "mon-email@example.com"

# Relier ce dossier au dépôt GitHub
git remote add origin https://github.com/MonPseudo/portfolio-infra.git

En résumé :

• git init → « Ce dossier est maintenant suivi par Git »
• git config → « Voici qui fait les modifications »
• git remote add → « Voici où envoyer le code en ligne »

4. Le fichier .gitignore (CRITIQUE)

C’est le premier fichier à créer avant d’envoyer quoi que ce soit.

Le .gitignore dit à Git : « Ces fichiers existent sur le serveur, mais tu ne dois jamais les envoyer sur GitHub. »

Pourquoi ? Parce que mon dépôt est public. Si mes mots de passe se retrouvent dedans, n’importe qui peut les lire.

nano .gitignore

# Secrets (mots de passe de la base de données etc.)
.env

# Fichiers uploadés sur WordPress (images, PDF...)
wp-content/uploads/

# Config WordPress (contient des infos sensibles)
wp-config.php

# Fichiers système inutiles
*.log
.DS_Store
Thumbs.db

Ce que ça donne concrètement :

💡 J’ai aussi créé un fichier .env.example qui montre la structure du .env mais sans les vrais mots de passe. Comme ça, quelqu’un qui clone mon projet sait quelles variables il doit remplir.

nano .env.example

MYSQL_ROOT_PASSWORD=à_remplacer
MYSQL_DATABASE=à_remplacer
MYSQL_USER=à_remplacer
MYSQL_PASSWORD=à_remplacer
WORDPRESS_DB_HOST=db:3306
WORDPRESS_DB_NAME=à_remplacer
WORDPRESS_DB_USER=à_remplacer
WORDPRESS_DB_PASSWORD=à_remplacer

5. Premier envoi sur GitHub

# Voir ce que Git a détecté
git status

# Ajouter les fichiers un par un (pas "git add ." à l'aveugle)
git add .gitignore .env.example docker-compose.yml nginx/

# Créer le premier commit (la première "photo")
git commit -m "Init: architecture Docker + config Nginx"

# Envoyer sur GitHub
git push -u origin main

Git me demande mon identifiant GitHub et mon token PAT (pas mon mot de passe).

6. La discipline des commits (Atomic Commits)

Un mauvais commit :

git add .
git commit -m "modifications"

→ On ne sait pas ce qui a changé, ni pourquoi. Inutile pour l’historique.

Un bon commit (atomic) :

# Je modifie UN seul truc → je commit CE truc
git add nginx/default.conf
git commit -m "Nginx: ajout cache 30j pour les images"

La règle : Un commit = une modification logique = un message clair.

Voici des exemples de bons messages :

Démarche a suivre :

# 1. Qu'est-ce qui a changé ?
git status

# 2. Vérifier le contenu des changements
git diff

# 3. Ajouter uniquement ce qui concerne MA modification
git add fichier_modifié

# 4. Décrire ce que j'ai fait
git commit -m "Explication courte et claire"

# 5. Envoyer sur GitHub
git push

8. Et si je dois tout redéployer sur un nouveau serveur ?

C’est tout l’intérêt de Git + Docker : je peux reconstruire
mon infrastructure en 4 commandes.

# 1. Récupérer mon projet depuis GitHub
git clone https://github.com/MonPseudo/portfolio-infra.git
cd portfolio-infra

# 2. Créer le fichier de secrets (il n'est pas sur GitHub)
cp .env.example .env
nano .env
# → Remplir avec les vrais mots de passe

# 3. Verrouiller le fichier
chmod 600 .env

# 4. Tout lancer
docker compose up -d

C’est ce qu’on appelle « Infrastructure as Code » : toute mon infrastructure est décrite dans des fichiers texte versionnés. Je n’ai rien à configurer à la main, tout est dans le dépôt.

C’est aussi pour ça que le .env.example existe : sans lui, quelqu’un qui clone le projet ne saurait pas quelles variables créer.

9. Commandes utiles pour la suite

# Voir l'historique de tous mes commits
git log --oneline

# Voir ce qui a changé depuis le dernier commit
git status

# Voir le détail des modifications
git diff

# Vérifier que .env n'a JAMAIS été envoyé sur GitHub
git log --all --full-history -- .env

# Vérifier ma configuration Git
git config --list

Ce que j’ai compris

• Git ne sauvegarde pas mes fichiers automatiquement. C’est moi qui décide quoi envoyer et quand.
• Le .gitignore est la première barrière de sécurité : il empêche les secrets d’atterrir sur GitHub.
• Un bon historique Git, c’est comme un journal de bord : chaque commit raconte ce qui a été fait et pourquoi.
• git add . c’est dangereux → je préfère ajouter les fichiers un par un pour garder le contrôle.
• Le dépôt public sur GitHub, c’est ma vitrine professionnelle. Une personne peut voir si je travaille proprement ou si je fais n’importe quoi.