J'utilise Git comme un checkpoint dans les jeux vidéo

Toki Rak — Fri, 20 Mar 2026 22:34:38 +0000

L'idée derrière tout ça

Quand je travaille sur plusieurs tâches en parallèle, j'oublie facilement où j'en suis. Surtout quand une urgence tombe et que je dois tout lâcher.

Étant passionné de jeux vidéo, j'ai remarqué un truc : avant d'affronter un boss, on sauvegarde. Si on meurt, on reprend au checkpoint, pas au début du jeu.

J'ai appliqué ce principe à Git. Résultat : je ne perds plus jamais le fil de mes développements.

Mon workflow en pratique

Imaginons que je dois créer une page détail produit e-commerce avec :

Les infos du produit
Les avis clients

Étape 1 : Créer la structure de base

Je crée ma route et j'affiche une page statique.

git add -A
git commit -m "step 1: créer page produit avec données statiques"

Étape 2 : Rendre la page dynamique

Je récupère les vraies données depuis la base.

git add -A
git commit -m "step 2: récupérer données produit et rendre dynamique"

Les cheat codes (aka les mocks)

Comme dans les jeux vidéo où on utilise des cheat codes, j'utilise des données mockées pour avancer sans attendre les vraies données.

Dans notre exemple, on n'a pas encore d'avis clients. Je mock donc les données et je marque clairement ce commit :

git add -A
git commit -m "WIP - mock avis clients (ne pas merger)"

Sauvegarder avant de changer de partie

Comme quand un pote débarque et veut jouer à un autre jeu, je sauvegarde ma progression avant de switcher de tâche :

git add -A
git commit -m "WIP - mise en place cache (en cours)"

Pour reprendre plus tard, je fais :

git reset --soft HEAD~1

Le commit est annulé mais mes fichiers restent indexés. Exactement comme je les ai laissés. (Plus pratique que git stash)
Une fois la tâche terminée, je fais un commit normal sans WIP.

Le nettoyage final (avant d'affronter le boss)

Avant de créer ma Pull Request, je nettoie mes commits :

Avant le rebase :

HEAD → mise en cache des données (fini)
       WIP - mock avis clients  
       step 2: données dynamiques
       step 1: page produit statique

L'éditeur interactif qui s'ouvre :

# git rebase -i HEAD~4

reword a1b2c3d step 1: créer page produit avec données statiques
fixup e4f5g6h step 2: récupérer données produit et rendre dynamique  
drop i7j8k9l WIP - mock avis clients (ne pas merger)
fixup m1n2o3p mise en place cache

Actions :

Je renomme (reword) le premier commit
Je garde (fixup) les autres commites non wip
Je supprime (drop) tous les commits WIP

L'éditeur interactif s'ouvre à nouveau :

# Je met le vrai nom conventionnée
feat: ajout page détail produit avec affichage avis clients

Résultat final :

$ git log --oneline
a1b2c3d feat: ajout page détail produit avec affichage avis clients

Mes alias pour aller plus vite

J'ai créé deux alias Git pour faciliter ce workflow :

Sauvegarder rapidement :

git config --global alias.wip "commit -am 'WIP - git unwip pour reprendre'"

Reprendre le chantier :

git config --global alias.unwip "reset --soft HEAD~1"

Maintenant je fais juste git wip et git unwip. Simple et efficace.

Conclusion

Ce workflow m'aide à jongler entre plusieurs projets et tâches sans me perdre. C'est pas une règle universelle, juste ce qui marche pour moi.

Et vous, vous sauvegardez comment vos "parties" de dev ? 🎮

Configuration Xdebug sur PHPSTORM + Windows + WSL + Docker

Toki Rak — Sun, 15 Feb 2026 19:45:27 +0000

Si vous développez en PHP sous Windows avec WSL et Docker, vous avez probablement déjà galéré avec XDebug. Entre les IP qui changent, les containers qui ne communiquent pas avec PHPStorm, et les configs qui marchent un jour mais plus le lendemain... c'est frustrant.

J'ai perdu pas mal d'heures à faire marcher ce setup. Voici la config qui fonctionne chez moi, et surtout, les pièges à éviter.

Ce dont vous avez besoin:

Docker compose qui utilise une image docker PHP et xdebug déjà installé et activé

Étape 1: Trouver votre IP windows (WSL)

Ouvrir un terminal windows (ou powershell) et executer la commande:

ipconfig

Récupérer l'adresse IP correspondant à la configuration:
Carte Ethernet VEthernet(WSL (Hyper-V firewall))

Étape 2: Créer le fichier Xdebug

Créer un fichier de configuration xdebug.ini (pour ma part je l'ai mis sur la racine du projet) et y ajouter les paramètres nécessaires:

zend_extension=xdebug.so
xdebug.mode=debug
xdebug.client_host=172.22.128.1  # Remplacez par votre IP WSL
xdebug.discover_client_host=0
xdebug.start_with_request=yes
xdebug.client_port=9003  
xdebug.cli_color=1

Étape 3: Monter le volume dans docker compose ou docker:

Ajouter une ligne dans le sections volumes de docker-compose.yaml pour surcharger le fichier de configuration de xdebug dans le container php

volumes:
  - ./xdebug.ini:/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

(Ou bien directement le copier dans le même chemin dans Dockerfile lors du build si vous n'utilisez pas docker compose)

Étape 4: Configurer PHPStorm:

Relancer votre projet, puis dans PHPStorm:

Activer l'écoute du debugger en cliquant sur l'icône de téléphone en haut à droite
(ou via Run > Start Listening for PHP Debug Connections)
Chargez une page de votre application. PHPStorm devrait afficher une popup "Incoming Connection from Xdebug" → Acceptez
Allez dans Settings > PHP > Servers et vérifiez les path mappings :
Le path de votre projet local doit pointer vers la racine de votre projet dans le container

Les pièges courants (et comment les éviter)

L’IP qui change : Si votre config ne fonctionne pas du jour au lendemain, vérifiez votre adresse IP et mettez à jour xdebug.ini
Plusieurs cartes « VEthernet WSL » : Si vous en avez plusieurs, testez chaque IP jusqu’à trouver la bonne. Oui c’est chiant, mais c’est rapide.
Mapping incorrect : Si des liens/fichiers fonctionnent et pas d’autres, verifier bien que le mapping entre le projet sur PHPStorm pointe bien que sur l’absolute path du serveur

Voilà ! Avec cette config, Xdebug devrait fonctionner sans problème dans votre environnement Windows + WSL + Docker + PHPStorm.

Bon débogage !

Forem: Toki Rak