Git Cheat Sheet

01Carte des commandes quotidiennes

Cherchez d’abord l’intention : inspecter, préparer, enregistrer, brancher, synchroniser, mettre de côté ou comparer. La commande vient ensuite.

Inspecter

git status
git diff
git diff --staged
git log --oneline --graph --decorate --all
git show
git remote -v
git branch -vv

Préparer et enregistrer

git add <path>
git add -p
git restore --staged <path>
git commit -m "message"
git commit --amend

Branches

git switch <branch>
git switch -c <branch>
git branch
git branch -d <branch>
git push -u origin <branch>

Synchroniser

git fetch
git pull
git pull --rebase
git push

Mettre temporairement de côté

git stash push -m "description"
git stash list
git stash show
git stash apply
git stash pop
git stash drop

Comparer un autre point

git diff branch-a..branch-b
git show <commit>
git log <branch>

Impact principal des familles de commandes
Intention	Ce que cela change	Ce que cela ne change pas	Erreur fréquente / récupération
`status`, `diff`, `log`, `show`	Rien : lecture seule.	Fichiers, staging, commits et remote.	Commencez ici avant une opération corrective.
`add`, `add -p`, `restore --staged`	Le staging area.	Les edits du working tree et l’historique existant.	Utilisez restore --staged pour retirer sans perdre l’edit.
`commit`, `amend`	L’historique local ; amend remplace le dernier commit.	Le remote tant qu’aucun push n’a lieu.	N’amendez pas sans coordination un commit déjà partagé.
`fetch`, `pull`, `push`	Les références distantes, puis éventuellement la branche locale ou distante.	Fetch seul ne modifie pas vos fichiers.	Choisissez merge ou rebase consciemment ; évitez une règle globale non comprise.
`stash apply`, `pop`, `drop`	Apply restaure et conserve ; pop restaure puis retire si possible ; drop retire.	Aucun de ces gestes ne publie un commit.	Préférez apply si vous voulez vérifier avant de supprimer l’entrée.

Avec git add -p, vous choisissez des fragments cohérents d’un même fichier. Inspectez ensuite avec git diff --staged : le commit doit raconter une seule intention.

Question

Vous vous rappelez l’opération, mais affecte-t-elle les fichiers, le staging, l’historique local ou le remote ?

Preuve attendue

Vous pouvez annoncer l’état modifié avant d’exécuter chaque commande d’un scénario.

Défi

À partir de changements mélangés, construisez deux commits ciblés, publiez une branche, mettez un edit de côté et comparez-la à main.

Ouvrir le Lab de cette section

02Rebase sans mysticisme

Rebase identifie les commits propres à la branche courante depuis l’ancêtre commun, puis rejoue leurs changements sur une nouvelle base. Les snapshots peuvent se ressembler, mais les commits rejoués ont de nouvelles identités.

Avant

      A---B  feature
     /
D---E---F---G  origin/main

Après

D---E---F---G  origin/main
             \
              A'---B'  feature

A′ et B′ appliquent les changements de A et B sur G, mais leurs parents, contenus calculés et identifiants de commit sont nouveaux. Un conflit peut arrêter chaque replay séparément.

Inspectez le working tree ; committez ou stashez les changements inachevés.
git fetch origin
git switch feature/my-work
git rebase origin/main
Résolvez un conflit, puis indexez les fichiers corrigés.
git rebase --continue
Répétez, testez, inspectez le graphe, puis poussez selon la situation.

git rebase <base>git rebase --continuegit rebase --abortgit rebase --skip

Règle de l’historique partagé

Ne rebasez pas des commits sur lesquels d’autres personnes travaillent déjà, sauf coordination explicite. Un push de l’historique réécrit peut nécessiter --force-with-lease, option avancée qui refuse normalement d’écraser un remote ayant évolué à votre insu. Le simple --force n’est pas une routine.

git rebase --skip abandonne le patch actuellement rejoué. Ce n’est pas une solution générique aux conflits.

git pull --rebase est une commodité : fetch, puis rebase des commits locaux sur l’upstream mis à jour. Il ne remplace pas l’apprentissage des bases, des branches et du graphe.

Question

Votre code est toujours présent, mais chaque commit possède une nouvelle identité. Qu’est-ce qui a changé ?

Preuve attendue

Vous dessinez l’ancêtre commun, l’ancienne base, la nouvelle base et les commits rejoués avant et après.

Défi

Rebasez deux commits locaux sur un main avancé, résolvez un conflit pendant le replay, puis comparez les anciennes et nouvelles identités.

Ouvrir le Lab de cette section

03Fast-forward, merge commit et squash

Deux intégrations peuvent produire les mêmes fichiers tout en racontant des histoires différentes. Squash n’est pas un type de fast-forward : l’un crée un nouveau commit net, l’autre avance simplement une référence.

Choisir selon le graphe et l’information à préserver
Méthode	Graphe obtenu	Commits de feature visibles ?	Réécriture ?	Usage courant
Fast-forward normal	La référence avance ; aucun commit de merge.	Oui	Non	Branche sans divergence.
`git merge --ff-only`	Avance ou refuse si le graphe diverge.	Oui	Non	Garde-fou pour historique strictement linéaire.
Merge divergent ordinaire	Merge commit à deux parents.	Oui	Non	Branches partagées divergentes.
`git merge --no-ff <branch>`	Merge commit même si un FF était possible.	Oui	Non	Préserver explicitement un point d’intégration.
Squash merge	Un nouveau commit contient le résultat net.	Non	Pas sur la cible ; la séquence n’y entre pas.	Feature utile mais commits internes bruyants.
Rebase puis fast-forward	Commits rejoués, puis référence avancée.	Oui	Oui	Historique linéaire avant publication coordonnée.

# fast-forward
A---B---C  main, feature

# merge commit
A---B---M  main
     \ /
      C    feature

# squash result
A---B---S  main
     \
      C1--C2  feature

La ligne de commande git merge --squash, l’option GitHub « Squash and merge » et le squash d’un interactive rebase combinent du travail, mais ne représentent pas la même opération ni le même moment du workflow.

Question

Les fichiers terminent dans le même état, mais l’historique raconte une autre histoire.

Preuve attendue

Vous pouvez prédire le nombre de parents, l’ascendance des commits de feature et le refus éventuel de --ff-only.

Défi

Choisissez et justifiez une stratégie pour une petite feature jetable, une feature bruyante relue, une release dont le point d’intégration compte et une branche strictement linéaire.

Ouvrir le Lab de cette section

04Interactive rebase et historique local propre

Quand le travail est juste mais que l’historique conserve chaque hésitation, git rebase -i HEAD~N permet de préparer des commits relisibles avant leur partage.

Todo interactif

pick a1b2c3d start feature
reword b2c3d4e actually fix feature
squash c3d4e5f fix typo
fixup d4e5f6a remove debug output
drop e5f6a7b accidental debug file
pick f6a7b8c add test

Résultat visé

A'  Implement status feature
B'  Add status feature test

pick: Conserver le commit tel qu’il sera rejoué.
reword: Conserver le contenu et modifier le message.
edit: Faire une pause pour modifier le contenu ou découper le commit.
squash: Combiner avec le commit précédent et éditer le message final.
fixup: Combiner avec le précédent et écarter normalement le message du fixup.
drop: Retirer le commit et donc son changement, sauf s’il est apporté ailleurs.
Réordonner: Changer l’ordre de replay ; le comportement peut changer et des conflits peuvent apparaître.

Mauvais usage : réécrire une branche de production partagée depuis longtemps uniquement pour embellir le graphe.

Niveau supérieur : préparer les fixups automatiquement

git commit --fixup <commit> crée un commit marqué pour une cible ; git rebase -i --autosquash réorganise le todo. Vérifiez toujours le plan avant de l’appliquer.

Question

Le travail est correct, mais l’historique enregistre chaque hésitation.

Preuve attendue

Cinq commits locaux deviennent deux commits cohérents, avec l’état final attendu et de nouvelles identités.

Défi

Rewordez un commit, squashez-en un, fixupez-en un, retirez le debug accidentel et gardez le test séparé.

Ouvrir le Lab de cette section

05Annuler, récupérer et déplacer le travail

La première question n’est pas « quelle commande annule ? », mais « le changement est-il committé, et a-t-il été partagé ? ». La réponse détermine si vous pouvez réécrire ou devez ajouter un événement correctif.

Décision selon l’état du changement
État	But	Route	Effet
Edit non committé	Jeter l’edit du fichier	`git restore <path>`	Destructif pour les modifications du working tree ciblées.
Indexé par erreur	Retirer du prochain commit	`git restore --staged <path>`	Conserve l’edit dans le working tree.
Dernier commit local	Corriger contenu ou message	`git commit --amend`	Remplace le commit et change son identité.
Mauvais commit partagé	Inverser sans réécrire	`git revert <commit>`	Ajoute un nouveau commit inverse.
Branche déplacée	Retrouver un ancien tip local	`git reflog`	Affiche des mouvements locaux récents ; rétention non garantie indéfiniment.
Commit utile ailleurs	Appliquer son changement ici	`git cherry-pick <commit>`	Crée un nouveau commit sur la branche courante.

`git reset --soft <target>`

Déplace la branche ; conserve le contenu indexé et le working tree.

`git reset --mixed <target>`

Déplace la branche ; remet le staging à la cible ; conserve le working tree.

`git reset --hard <target>`

Déplace la branche, le staging et le working tree. Le travail non committé peut être détruit.

stash apply conserve l’entrée après restauration ; stash pop la retire si l’application réussit. Utilisez apply lorsque vous voulez contrôler le résultat avant suppression.

Question

Le commit a disparu du graphe de branche. Git ne l’a pas nécessairement oublié.

Preuve attendue

Avant chaque geste, vous prédisez la position de la branche, le staging, le working tree et l’historique partagé.

Défi

Résolvez cinq scénarios : unstage, commit local à conserver, commit partagé à inverser, commit retrouvé par reflog et commit déplacé par cherry-pick.

Ouvrir le Lab de cette section

06Déployer un site avec GitHub et cPanel

Le workflow pull garde une source GitHub lisible et une étape de publication explicite : pousser le commit ne modifie pas encore le site ; cPanel doit d’abord mettre à jour son dépôt géré, puis exécuter les tâches de déploiement.

VS Code→commit local→GitHub→dépôt géré par cPanel→.cpanel.yml→répertoire public

Route simple sans clé SSH gérée localement

Cette recette suppose un dépôt GitHub public cloné par son URL HTTPS. Un dépôt privé nécessite une authentification supplémentaire ; ne publiez jamais des secrets pour contourner cette exigence.

Préparez le dépôt GitHub public et gardez uniquement les sources destinées à être publiques.
Ajoutez un fichier .cpanel.yml à la racine, validez-le, committez-le et poussez-le.
Dans cPanel, ouvrez Files → Git Version Control.
Clonez l’URL HTTPS publique dans un chemin de dépôt hors du document root.
Ouvrez Manage → Pull or Deploy.
Choisissez Update from Remote, puis confirmez le dernier commit.
Choisissez Deploy HEAD Commit pour exécuter les tâches.
Inspectez les fichiers déployés, ouvrez le site et vérifiez le changement attendu.

Exemple pédagogique sûr

---
deployment:
  tasks:
    - export DEPLOYPATH=/home/ACCOUNT/public_html/
    - /bin/mkdir -p "$DEPLOYPATH"
    - /usr/bin/rsync -av ./public/ "$DEPLOYPATH"

---: Début explicite du document YAML.
deployment / tasks: Liste ordonnée des commandes de déploiement exécutées par cPanel.
DEPLOYPATH: Variable de destination. ACCOUNT est un placeholder à remplacer dans votre propre environnement.
mkdir -p: Crée la destination si elle n’existe pas.
rsync -av ./public/: Déploie uniquement le contenu public prévu. Aucun --delete, aucun wildcard de racine.

La famille de déploiement Dercetech utilise également une variable de destination, mkdir et rsync depuis un dossier dédié ./www/. Les opérations de sauvegarde, suppression et synchronisation destructive propres à la production ne sont volontairement pas reproduites ici : elles exigent une revue opérationnelle séparée.

À ne pas copier

Ne déployez jamais * depuis la racine du dépôt : vous pourriez inclure .git, .env, des tests, caches, sources privées ou configurations de développement. .gitignore contrôle ce qui entre dans Git ; .cpanel.yml contrôle ce qui part en production.

Ce cours utilise le pull deployment : Update from Remote, puis Deploy HEAD Commit. Le direct push vers le dépôt géré par cPanel est une autre configuration et reste hors de cette recette.

Matrice finale

Intention	Commande ou action	Garde-fou
Comprendre l’état	`status`, `diff`, `log --graph`, `show`	Lire avant d’agir.
Composer un commit	`add -p` → `diff --staged` → `commit`	Une intention cohérente.
Intégrer	`merge`, `--ff-only`, squash ou rebase	Décider quelle histoire conserver.
Nettoyer le local	`rebase -i`, `commit --fixup`	Avant partage ou avec coordination.
Récupérer	`restore`, `revert`, `reset`, `reflog`, `cherry-pick`	Identifier l’état et le partage d’abord.
Déployer	push → Update from Remote → Deploy HEAD Commit	Dossier public explicite, manifeste vérifié.

Question

Le dépôt contient le bon site. Le serveur contient encore la copie de mardi dernier. Quelle étape manque ?

Preuve attendue

Vous reliez un commit précis à GitHub, au HEAD du dépôt cPanel, au manifeste de fichiers et au résultat visible.

Défi

Réparez un YAML sanitizé, refusez un wildcard dangereux, ordonnez les actions cPanel et trouvez pourquoi un commit poussé n’est pas encore visible.

Ouvrir le Lab de cette section