Git, GitHub & sauvegardes

Vous venez de poser un agent qui va écrire du code à toute vitesse. Avant qu’il ne touche quoi que ce soit d’important, on installe le filet : Git, pour que chaque changement soit réversible, et GitHub, pour que votre travail vive ailleurs que sur ce seul petit boîtier. Parce qu’un mini-PC, ça peut griller, se faire voler, ou se prendre un rm de trop. Votre code, lui, ne doit jamais disparaître avec.

Pourquoi c’est non négociable (surtout avec un agent)

Un agent de code va vite, et il a confiance en lui. La plupart du temps c’est génial ; parfois il casse quelque chose. Git transforme ça en non-événement :

• Chaque commit est un point de restauration. L’agent a tout cassé ? git restore ou git reset, et vous revenez à l’état d’avant en une seconde. C’est le « annuler » ultime.
• Vous voyez exactement ce qui a changé. git diff vous montre, ligne par ligne, ce que l’agent a touché. Vous relisez avant de valider, c’est le cœur du métier (voir Sécuriser les accès).
• GitHub met votre code hors de portée des catastrophes. Disque mort, vol, fausse manip : votre code est sur GitHub, intact. Vous le récupérez sur n’importe quelle machine en une commande.
• Et vous pouvez partager. Donner accès à un collègue, bosser à plusieurs, ouvrir en open source : tout passe par GitHub.

Configurer Git sur la machine

Trois lignes, une fois pour toutes. Git a besoin de savoir qui vous êtes (ça signe vos commits) :

git config --global user.name "Ton Prénom Nom"
git config --global user.email "[email protected]"
# Quelques défauts sains
git config --global init.defaultBranch main   # la branche par défaut s'appelle "main"
git config --global pull.rebase false          # comportement de pull prévisible

Donner à la machine l’accès à GitHub

Votre machine doit prouver à GitHub qu’elle a le droit de pousser. Deux chemins ; prenez celui qui vous parle.

Votre premier dépôt, et l’agent qui s’en sert

cd ~/mon-projet
git init
# Le fichier qui dit à git quoi IGNORER, crucial
cat > .gitignore <<'EOF'
node_modules/
.env
*.log
dist/
EOF
git add -A
git commit -m "Premier jet"
# Crée le dépôt distant et pousse (avec gh, c'est une ligne)
gh repo create mon-projet --private --source=. --push

Une fois en place, demandez à votre agent de gérer git pour vous : « commits réguliers avec des messages clairs », « crée une branche pour cette fonctionnalité », « ouvre une pull request ». Vous pouvez même l’inscrire dans votre fichier mémoire : « commit après chaque étape validée, messages conventionnels, ne pousse sur main qu’avec mon accord. »

Les sauvegardes : la règle 3-2-1

GitHub sauve votre code. Mais votre mini-PC contient bien d’autres choses qui ne sont pas dans git : vos fichiers .env, vos bases de données, des données générées, des configs système. Pour celles-là, on applique la règle d’or de la sauvegarde :

Trois pièges qu’on ne découvre qu’au moment de restaurer

Visez le disque par son étiquette, jamais par son chemin

Un disque externe ne se monte pas toujours au même endroit. Si le dossier existe déjà, votre bureau ajoute un chiffre et monte sur /media/vous/1TB1, en laissant /media/vous/1TB derrière lui sous forme de dossier vide sur le disque système.

Le test naïf [ -d "$DEST" ] passe très bien. Et votre sauvegarde part tranquillement sur le disque système en croyant écrire sur l’externe.

# on résout par l'étiquette, et on exige un vrai point de montage
DEST="$(findmnt -rn -S LABEL=1TB -o TARGET 2>/dev/null | head -1)"
[ -n "$DEST" ] && mountpoint -q "$DEST" \
  || { echo "SSD externe non monté, sauvegarde annulée"; exit 1; }

Une liste écrite en dur oublie les nouveaux venus

Un script qui énumère vos bases à la main ne sauvegarde jamais le projet que vous avez créé le mois dernier. Et il ne le dit pas. Balayez ce qui tourne réellement :

for c in $(docker ps --format '{{.Names}}'); do
  # on sonde la présence de l'outil plutôt que le nom de l'image :
  # ça attrape aussi pgvector, timescaledb et les autres dérivés
  docker exec "$c" sh -c 'command -v pg_dumpall' >/dev/null 2>&1 || continue
  docker exec "$c" pg_dumpall -U postgres | gzip > "$DEST/$c.sql.gz"
done

Une reconstruction destructive doit être atomique

Un script qui supprime la base puis la reconstruit vous laisse sans rien s’il meurt au milieu. Construisez à côté, puis renommez : sur un même système de fichiers, le renommage est atomique.

sqlite3 base.sqlite.tmp < schema.sql
# … remplissage …
mv base.sqlite.tmp base.sqlite      # bascule instantanée, ou rien

Et avant la bascule, vérifiez : intégrité, nombre d’index, plancher de lignes. Une reconstruction qui aboutit à moitié passe sinon pour un succès.