Sauvegarder mes étapes (commit + push)

En une phrase : enregistrer vos modifications localement (commit) puis les publier sur GitHub (push) pour que les autres machines de l'agence puissent les récupérer. Difficulté : facile une fois compris Temps : 1 minute

Quand l'utiliser

• Vous avez terminé un changement de code propre et testé
• Fin de séance de travail
• Avant de fermer votre machine

Avant de commencer

• [ ] Le code compile (build vert)
• [ ] Vous avez relu vos changements (git diff)
• [ ] Aucune clé / mot de passe / fichier .env n'est dans vos modifications

Étapes

1. Voir ce qui a changé

git status

Affiche les fichiers modifiés en rouge (pas encore pris en compte) ou en vert (prêts à être sauvegardés).

2. Voir le détail des changements (optionnel mais recommandé)

git diff

Vous montre ligne par ligne ce qui change. Vérifiez qu'il n'y a rien de bizarre (clé hardcodée, debug log oublié…).

3. Sélectionner les fichiers à sauvegarder (staging)

Cas standard — tout ce qui a changé :

git add -A

Cas précis — juste un fichier :

git add chemin/vers/le/fichier.cs

Évitez git add . si vous avez des fichiers temporaires non listés dans .gitignore — ils risquent d'être inclus.

4. Créer la photo (commit)

git commit -m "fix(dpgf): corriger affichage quantités à 0 sur lots vides"

Format imposé : <type>(<scope>): <description en français>

• types : feat (nouveauté), fix (correction), refactor (réorga sans changement fonctionnel), docs, test, chore
• scope : DPGF, sheets, site, mcp, ci, etc.
• Description courte, à l'impératif

5. Envoyer au cloud (push)

git push

Une ligne du style To https://github.com/91STUDIO971/auguste-revit.git ... main -> main confirme l'envoi.

Schéma complet

Vérifier que ça a marché

• git status affiche nothing to commit, working tree clean
• git log -1 montre votre commit avec votre nom
• Sur GitHub, votre commit apparaît dans la liste

Si ça ne marche pas

Symptôme	Que faire
nothing to commit mais vous savez avoir modifié	Vérifier que vous êtes dans le bon dossier (pwd)
! [rejected] ... fetch first au push	Quelqu'un a poussé avant vous → faire git pull --rebase puis re-push
Vrai conflit de merge	Voir reparer-apres-merge-casse.md
Permission denied (publickey)	SSH ne marche pas — utiliser HTTPS : git remote set-url origin https://github.com/91STUDIO971/auguste-revit.git
failed to push some refs	Quelqu'un a force-pushé → arrêter, demander à l'administrateur

Ce qu'il ne faut JAMAIS faire

• git push --force ou git push -f sans confirmation explicit l'administrateur — écrase l'historique des autres
• Commit avec --no-verify pour bypasser les hooks — ces vérifs existent pour une raison
• Commit d'un fichier .env, *.key, secret.json — voir DOC-RULES.md

Quand vous avez fini

Le hook /handoff met à jour automatiquement handoff/session-courante.md à la fin de session — invoquez-le à l'oral à votre LLM de dev en disant « fais le handoff ».

---

Public cible : développeur futur (et utilisatrices à terme — étape 3) Dernière vérification : 2026-05-15