DEV Community

Cover image for J'utilise Git comme un checkpoint dans les jeux vidéo
Toki Rak
Toki Rak

Posted on

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

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"
Enter fullscreen mode Exit fullscreen mode

É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"
Enter fullscreen mode Exit fullscreen mode

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)"
Enter fullscreen mode Exit fullscreen mode

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)"
Enter fullscreen mode Exit fullscreen mode

Pour reprendre plus tard, je fais :

git reset --soft HEAD~1
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 :**
Enter fullscreen mode Exit fullscreen mode


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


**Reprendre le chantier :**
Enter fullscreen mode Exit fullscreen mode


bash
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 ? 🎮
Enter fullscreen mode Exit fullscreen mode

Top comments (0)