Masterclass Git · version 1mis à jour le 21 septembre 2026

Git, de git init au cherry-pick

Les commandes de tous les jours, le rebase sans avoir peur de tout casser, réparer une erreur, puis la vie en équipe : main, dev, int, Git flow, faire passer une seule feature d'une branche à l'autre. Ce qui sert vraiment au travail, dans l'ordre où tu en auras besoin.

Trois parties, seize sections, les pièges et l'antisèche à la fin. Chaque bloc de commandes se copie d'un clic.

Partie 1 · Les commandes de tous les jours

Une quinzaine de commandes font l'essentiel de tes journées. Elles déplacent toutes ton travail d'un endroit à un autre — une fois que tu vois les quatre endroits, tu ne tapes plus au hasard.

Ce que Git fait vraiment

Git n'enregistre rien tout seul. Tu choisis ce qu'il doit photographier, puis tu prends la photo. Quatre endroits, et chaque commande fait passer ton travail de l'un à l'autre.

Git est un historique de ton projet. Pas un historique automatique comme celui d'un traitement de texte : un historique que tu écris, une étape à la fois, quand tu décides qu'une étape est finie.

Ton dossier : les fichiers tels qu'ils sont sur ton disque. Tu les modifies, Git remarque qu'ils ont changé, il ne garde rien.
La zone d'attente (on dit aussi l'index, ou le staging) : ce que tu as choisi de mettre dans la prochaine photo. Ça te permet de ne photographier qu'une partie de ce que tu as touché.
Ton historique local : la suite des commits, rangée dans le dossier caché .git. Tout est sur ta machine : tu peux commiter dans un train sans réseau.
Le serveur : la copie partagée, sur GitHub, GitLab ou autre. Par convention, il s'appelle origin. Rien n'y arrive tant que tu ne l'envoies pas.

Un dernier mot à connaître : HEAD. C'est « là où tu es » — le commit, en général le bout de la branche, sur lequel ton dossier est posé.

1
Ton dossier
Les fichiers que tu modifies. Git les voit, il ne garde rien.
git add →← git restore --staged
2
La zone d'attente
L'index : ce que tu as choisi de mettre dans la prochaine photo.
git commit →← git reset --soft
3
Ton historique
Les commits, dans le dossier caché .git. Sur ta machine seulement.
git push →← git fetch · git pull
4
Le serveur
origin : GitHub, GitLab… La copie que l'équipe partage.

Un commit, c'est une photo de tout le projet à un instant, avec un identifiant (le hash, du genre 4f9e2a1). Une branche, c'est une étiquette posée sur un commit — rien de plus, c'est pour ça qu'en créer une ne coûte rien.

Démarrer : git clone ou git init

Le projet existe déjà ? Tu le clones. Il n'existe pas ? Tu l'inities. Dans les deux cas, trois lignes de réglage d'abord, une fois pour toutes.

Avant ton premier commit sur une machine, dis à Git qui tu es : ton nom et ton email sont écrits dans chaque commit, et c'est eux que l'équipe verra. Prends l'email de ton compte GitHub ou GitLab, sinon tes commits n'y seront pas rattachés à ton profil.

Une fois par machine

git config --global user.name "Prénom Nom"
git config --global user.email "toi@exemple.fr"
git config --global init.defaultBranch main

Le projet existe : tu le récupères

git clone https://github.com/equipe/projet.git
cd projet

Tu pars de zéro

mkdir mon-projet && cd mon-projet
git init
# … ton premier commit, puis tu le relies à un dépôt vide créé sur GitHub :
git remote add origin https://github.com/toi/mon-projet.git
git push -u origin main

git clone télécharge tout : les fichiers, tout l'historique et toutes les branches, et règle origin pour toi. git init crée seulement le dossier .git : il n'y a encore rien sur aucun serveur.

Le premier fichier à écrire dans un projet neuf, c'est .gitignore : la liste de ce que Git doit ignorer. Les dépendances (node_modules/), les fichiers générés (dist/), et surtout les secrets (.env). Un secret poussé une seule fois reste dans l'historique : le supprimer du fichier ne suffit pas, il faut le changer.

Pour pousser vers GitHub, ton mot de passe ne marche pas : GitHub l'a retiré pour les commandes Git en 2021. Il te faut une clé SSH (tu clones alors avec l'adresse git@github.com:…) ou un jeton d'accès. La clé SSH se règle une fois et on n'en parle plus.

SourceFin du mot de passe pour Git sur GitHub (13 août 2021) : GitHub Blog, « Token authentication requirements for Git operations ». Clés SSH : docs.github.com, « Connexion à GitHub avec SSH ».

Le cycle de tous les jours : status, add, commit

Regarder, choisir, photographier. Cent fois par jour, dans cet ordre.

Toute ta journée tient dans une boucle : tu modifies, tu regardes ce qui a changé, tu choisis ce qui part, tu commites. git status est la commande que tu taperas le plus — elle te dit où tu es et quoi faire ensuite.

git status                  # ce qui a changé, ce qui est prêt à partir
git diff                    # le détail, ligne par ligne, de ce qui n'est pas encore ajouté
git add src/panier.ts       # mettre un fichier dans la zone d'attente
git add -p                  # choisir morceau par morceau ce qui part
git diff --staged           # relire ce qui va partir dans le commit
git commit -m "Ajoute le calcul des frais de port"
git log --oneline --graph   # l'historique, une ligne par commit

Un commit = une idée. « Ajoute le calcul des frais de port », pas « modifs du jeudi ». Le message dit ce que fait le commit, à l'impératif, et pourquoi si ce n'est pas évident. Dans six mois, c'est toi qui le reliras en cherchant d'où vient un bug.

Beaucoup d'équipes imposent un format : le numéro du ticket en tête, ou un préfixe comme feat: et fix: (la convention Conventional Commits). Avant ton premier commit dans un projet, lis les vingt derniers messages avec git log --oneline -20 et fais pareil.

Parler au serveur : fetch, pull, push

fetch regarde sans toucher, pull récupère et intègre, push envoie. Et quand le push est refusé, ce n'est jamais le moment de forcer.

git fetch télécharge ce que les autres ont poussé, mais ne touche ni à tes fichiers ni à tes branches. C'est la commande sans aucun risque : tu peux la taper à tout moment. git pull, c'est un fetch suivi de l'intégration dans ta branche — par un merge par défaut, ou par un rebase si tu le demandes (partie 2).

git remote -v                    # vers quel serveur pointe origin
git fetch                        # télécharger les nouveautés, sans rien modifier chez toi
git pull                         # récupérer et intégrer dans ta branche
git pull --rebase                # pareil, en rejouant tes commits par-dessus
git push                         # envoyer tes commits
git push -u origin ma-branche    # la première fois, pour une branche neuve

Le message que tout le monde rencontre la première semaine : ! [rejected] … (fetch first). Il veut dire que quelqu'un a poussé sur la même branche avant toi, et que ton historique n'a pas ses commits. La réponse : git pull --rebase, tu règles les conflits s'il y en a, puis git push. Forcer le push effacerait son travail.

Les branches : créer, changer, fusionner

Une branche coûte une commande. Un sujet = une branche, même quand tu travailles seul.

Une branche te laisse travailler sur un sujet sans toucher à main. Si ça ne marche pas, tu la jettes ; si ça marche, tu la fusionnes. Pour changer de branche, la commande moderne est git switch (depuis Git 2.23, en 2019). Tu verras encore git checkout partout dans les tutos : il marche toujours, il fait simplement trop de choses à la fois.

git branch                              # la liste ; l'étoile = là où tu es
git switch -c feature/panier            # créer une branche et y aller (= git checkout -b)
git switch main                         # revenir sur main
git merge feature/panier                # fusionner la branche dans celle où tu es
git branch -d feature/panier            # supprimer une branche déjà fusionnée
git push origin --delete feature/panier # la supprimer sur le serveur

Un conflit, c'est Git qui te dit : deux personnes ont modifié les mêmes lignes, je ne choisis pas à ta place. Il écrit les deux versions dans le fichier, entre des marqueurs :

<<<<<<< HEAD
const fraisDePort = 4.90;
=======
const fraisDePort = calculerFrais(panier);
>>>>>>> feature/panier

Tu gardes la bonne version (ou un mélange des deux), tu supprimes les marqueurs, puis git add du fichier et git commit. Tu paniques ? git merge --abort remet tout comme avant le merge. Ton éditeur (VS Code, par exemple) propose des boutons pour chaque conflit : sers-t'en, mais relis toujours le résultat.

Sourcegit switch et git restore arrivent avec Git 2.23 : GitHub Blog, « Highlights from Git 2.23 ». Référence des commandes : git-scm.com/docs/git-switch.

Partie 2 · Le rebase, et réparer ses erreurs

Le rebase fait peur parce qu'il réécrit l'historique. Une seule règle suffit à le rendre sans danger — et presque tout ce que tu casses dans Git se répare.

Le rebase, ce qu'il fait

Il décolle tes commits, et les rejoue un par un au bout de main. Comme si tu avais commencé ta branche ce matin.

La situation arrive tous les jours. Tu as créé ta branche lundi. Depuis, trois collègues ont fusionné leur travail dans main. Ta branche est partie d'un main qui n'existe plus. Pour te remettre à jour, deux façons :

Le merge fusionne main dans ta branche et ajoute un commit de fusion. Rien n'est réécrit, mais l'historique se remplit de losanges.
Le rebase met tes commits de côté, place ta branche au bout de main, et rejoue tes commits un par un. L'historique reste une ligne droite.

Le point à comprendre : les commits rejoués sont de nouveaux commits. Mêmes changements, mais nouveaux identifiants. Pour Git, ce ne sont plus les mêmes. C'est tout le danger du rebase, et on y revient dans la section suivante.

Avant : main a avancé pendant que tu codais

mainABC

ta brancheDE

Après git merge main

mainABC

ta brancheDEM

Après git rebase main

mainABC

ta brancheD′E′

Le merge garde l'histoire telle qu'elle s'est passée et ajoute un commit de fusion (M). Le rebase la réécrit : D et E sont rejoués après C et deviennent D′ et E′ — mêmes changements, nouveaux identifiants. Ta branche repart du dernier commit de main, en ligne droite.

Remettre ta branche à jour sur main

git switch feature/panier
git fetch
git rebase origin/main

Un conflit en route

# Git s'arrête sur le commit qui coince. Tu corriges le fichier, puis :
git add src/panier.ts
git rebase --continue

# Ce commit ne sert plus à rien ? Passe-le :
git rebase --skip

# Tu veux tout annuler et revenir à avant le rebase :
git rebase --abort

Pendant un rebase, les conflits arrivent commit par commit, pas tous d'un coup. Avec dix commits qui touchent le même fichier, tu peux régler dix fois le même genre de conflit. C'est une raison de plus de rebaser souvent : une fois par jour, les conflits restent petits.

La règle d'or, et le push d'après

On ne rebase jamais une branche sur laquelle quelqu'un d'autre travaille. Sur ta branche à toi, vas-y sans crainte.

Le rebase recrée tes commits. Si un collègue avait déjà récupéré les anciens, son historique et le tien ne se ressemblent plus : au prochain pull, il retrouve des commits en double et des conflits qu'il n'a pas causés. D'où la règle : on rebase seulement ce qui n'appartient qu'à toi. Ta branche de feature, oui. main, dev, develop, ou la branche d'un autre, jamais.

Après un rebase d'une branche déjà poussée, git push est refusé : le serveur a les anciens commits, toi les nouveaux. Il faut écraser la version du serveur. Deux options, et une seule est bonne.

git push --force-with-lease     # écrase, sauf si quelqu'un a poussé entre-temps
git push --force                # écrase sans regarder : à oublier

SourceDocumentation officielle de --force-with-lease : git-scm.com/docs/git-push. Le rebase et ses risques : Pro Git, « Rebaser (Rebasing) », en français.

Le rebase interactif : nettoyer avant de montrer

Tes quatorze commits « wip », « fix », « fix 2 » deviennent trois commits propres, juste avant la relecture.

En travaillant, on commite souvent et salement. C'est très bien : un commit fréquent, c'est un point de sauvegarde. Mais avant d'ouvrir ta pull request, tu peux réécrire ces commits-là — ils sont encore à toi seul. git rebase -i ouvre la liste dans ton éditeur.

Ouvrir la liste

git rebase -i HEAD~5         # retravailler les 5 derniers commits
git rebase -i origin/main    # tout ce qui n'est pas encore sur main

Ce que tu édites (le plus ancien en haut)

pick   a1b2c3d Ajoute le panier
fixup  e4f5a6b wip
fixup  9c8d7e6 fix typo
reword 1a2b3c4 frais de port
pick   5d6e7f8 Ajoute les tests du panier

Le mot	Ce qu'il fait
`pick`	Garde le commit tel quel.
`reword`	Garde le commit, te laisse changer son message.
`squash`	Le fond dans le commit du dessus, et te laisse fusionner les deux messages.
`fixup`	Pareil que squash, mais jette son message. Le plus utile.
`drop`	Supprime le commit.
`edit`	S'arrête sur ce commit pour que tu le modifies, puis `git rebase --continue`.

Tu peux aussi déplacer les lignes : l'ordre de la liste devient l'ordre des commits. Pour le tout dernier commit seulement, pas besoin de rebase : git commit --amend le modifie directement.

La version pro : quand tu corriges un commit précis, commite avec git commit --fixup a1b2c3d. Au moment de nettoyer, git rebase -i --autosquash origin/main range tout seul chaque correction sous le bon commit.

Merge ou rebase : qui choisit

Ce n'est pas une affaire de goût personnel, c'est une règle d'équipe. Voilà ce que coûte chaque option, pour comprendre la règle qu'on te donnera.

	Merge	Rebase	Squash merge (au moment de la PR)
L'historique	Vrai, avec les losanges et les commits de fusion.	Une ligne droite, facile à lire.	Un commit par PR sur main.
Les conflits	Une seule fois, pour tout.	Commit par commit.	Réglés dans la branche avant.
Le risque	Aucun, rien n'est réécrit.	Réécrit : jamais sur une branche partagée.	Les commits de la branche ne sont plus sur main.
Défaire une feature	Revert du commit de fusion.	Un revert par commit.	Un seul revert.

Réparer : les commandes qui sauvent

Presque rien n'est perdu dans Git. Ce qui a été commité se retrouve, même après un reset --hard ou un rebase raté.

Ce qui t'arrive	La commande
J'ai modifié un fichier et je veux revenir à sa dernière version commitée	`git restore fichier`
J'ai ajouté un fichier par erreur avec `git add`	`git restore --staged fichier`
Je me suis trompé de message au dernier commit	`git commit --amend -m "…"`
J'ai oublié un fichier dans le dernier commit	`git add fichier` puis `git commit --amend --no-edit`
Je veux défaire le dernier commit en gardant le travail	`git reset --soft HEAD~1`
Je veux tout jeter et revenir au dernier commit	`git reset --hard` — le travail non commité est perdu pour de bon
Un commit déjà poussé casse tout	`git revert <hash>` : un nouveau commit qui fait l'inverse, rien n'est réécrit
Je dois changer de branche, mais mon travail n'est pas prêt	`git stash`, puis plus tard `git stash pop`
J'ai tout cassé : rebase raté, reset de trop, branche supprimée	`git reflog`, puis `git reset --hard HEAD@{2}` (le bon numéro)

Les trois reset, parce qu'ils se confondent : tous ramènent la branche sur un commit plus ancien. --soft garde tes changements prêts à recommiter. --mixed (le défaut) les garde dans ton dossier, hors de la zone d'attente. --hard les jette.

Le reflog, c'est le filet de sécurité : le journal, sur ta machine, de chaque endroit où tu as été. Chaque commit, rebase, reset, changement de branche y laisse une ligne. Il est gardé par défaut 90 jours (30 pour les commits qui ne sont plus sur aucune branche). Tu y retrouves l'état d'avant la bêtise, et un reset --hard dessus te ramène là.

SourceDurées du reflog (gc.reflogExpire, gc.reflogExpireUnreachable) : git-scm.com/docs/git-gc. Les trois modes de reset : Pro Git, « Reset démystifié ».

Partie 3 · Git en équipe

Il n'y a pas un workflow Git, il y a celui de ton équipe. Il change d'une boîte à l'autre, et même d'un projet à l'autre — mais il se lit en cinq minutes si tu sais quoi regarder.

Chaque équipe a le sien

Quatre familles reviennent presque partout. Ton équipe utilise l'une d'elles, ou un mélange, avec ses propres noms de branches.

Un workflow répond à deux questions, et seulement deux : d'où part ta branche, et par où passe une feature pour arriver en production. Tout le reste — les noms, les préfixes, les outils — change d'une équipe à l'autre.

Le plus connu, Git flow, a été décrit par Vincent Driessen en 2010. Dix ans plus tard, il a ajouté une note en tête de son propre article : pour une application web mise en ligne en continu, il conseille un modèle plus simple, comme le GitHub flow. Git flow reste répandu, surtout là où on livre des versions numérotées. Aucun des quatre n'est le bon : chacun colle à une façon de livrer.

Trunk-based
mainbranches de quelques heures
Une feature part en prod
Fusionnée dans main le jour même. Pas finie ? Cachée derrière un interrupteur (feature flag).
Souvent chez
Équipes qui mettent en ligne plusieurs fois par jour, avec beaucoup de tests automatiques.
GitHub flow
mainfeature/…
Une feature part en prod
Une branche par sujet, une pull request relue, fusion dans main, mise en ligne.
Souvent chez
Startups, SaaS, open source. Le plus simple qui tienne à plusieurs.
Git flow
maindevelopfeature/…release/…hotfix/…
Une feature part en prod
feature → develop → une branche release/1.4 → main, avec un tag de version.
Souvent chez
Logiciels versionnés, applications mobiles, livraisons à date fixe.
Branches d'environnement
devintmain
Une feature part en prod
Une branche = un serveur. La feature monte une marche à la fois : dev, puis int (la recette), puis main (la prod).
Souvent chez
ESN, grands comptes, projets avec une recette client.

Les noms changent d'une équipe à l'autre, et beaucoup mélangent : un Git flow sans branche release, un GitHub flow avec une branche de recette. Ce qui compte, c'est de savoir d'où part ta branche et par où passe une feature pour arriver en prod.

SourceGit flow : Vincent Driessen, « A successful Git branching model » (2010, note de réflexion du 5 mars 2020). GitHub flow : docs.github.com, « Flux GitHub ». Trunk-based : trunkbaseddevelopment.com.

main, int, dev : faire monter une feature

Chaque branche correspond à un serveur. Une feature monte une marche à la fois : dev, puis int, puis main — la production.

C'est le modèle qu'on rencontre le plus souvent en ESN et chez les grands comptes, sous des noms qui varient : dev ou develop, int, recette, staging ou preprod, main, master ou prod. Le principe ne change pas.

dev : là où les features s'assemblent. Déployée sur un serveur de développement, souvent cassée, c'est normal.
int (intégration, recette) : ce que les testeurs ou le client vérifient. Plus stable.
main : la production. Ce qui y entre est en ligne.

Ta branche de feature part de la branche de base — souvent dev, parfois main : c'est la première question à poser (section 16). Tu y travailles, tu te remets à jour par rebase, tu ouvres une pull request vers dev. Ensuite, la promotion — dev vers int, puis int vers main — se fait en général par une pull request ou par la CI, rarement par toi à la main le premier mois.

Une feature, du ticket à la pull request

git switch dev
git pull
git switch -c feature/JIRA-123-panier

# … tes commits …

git fetch
git rebase origin/dev                       # se remettre à jour juste avant la PR
git push -u origin feature/JIRA-123-panier
# → ouvrir la pull request (ou merge request, sur GitLab) vers dev

Tout va bien tant que les features montent dans l'ordre où elles arrivent. Le problème commence le jour où dev contient trois features et qu'une seule est validée pour partir. Fusionner dev dans int ferait monter les trois. C'est le travail du cherry-pick.

Le cherry-pick : faire passer une seule feature

Tu ne fusionnes pas toute la branche : tu prends le commit de la feature validée, et lui seul, pour le recopier sur la branche d'à côté.

git cherry-pick prend les changements d'un commit et les rejoue sur la branche où tu te trouves. Le résultat est un nouveau commit : mêmes changements, nouvel identifiant. Dans les équipes à branches d'environnement, et en Git flow pour les correctifs, c'est une manœuvre de tous les jours.

Avant : trois features sur dev, seule F2 est validée

mainA

intA

devAF1F2F3

Après git cherry-pick -x <hash de F2>, sur int

mainA

intAF2′

devAF1F2F3

F2′ est une copie de F2 : les mêmes changements, un nouveau commit, un nouvel identifiant. F1 et F3 restent sur dev, en attendant leur validation. Un merge de dev dans int aurait fait monter les trois.

# 1. Trouver le ou les commits de la feature
git fetch
git log origin/dev --oneline --grep="JIRA-123"

# 2. Aller sur la branche qui doit la recevoir
git switch int
git pull

# 3. Recopier le commit (-x garde la trace de l'original dans le message)
git cherry-pick -x 4f9e2a1

# Plusieurs commits d'affilée, du plus ancien au plus récent (les deux inclus)
git cherry-pick -x 4f9e2a1^..b7c3d05

# Un conflit : tu corriges, puis
git add src/panier.ts
git cherry-pick --continue        # ou --abort pour tout annuler

git push

Si int est protégée (pas de push direct, ce qui est fréquent), fais la même chose sur une branche partie de int — git switch -c pick/JIRA-123-vers-int — et ouvre une pull request vers int.

Le squash merge aide beaucoup ici. Si les features entrent dans dev en un seul commit chacune, il y a un seul hash à recopier. Si une feature est éparpillée en huit commits mêlés à ceux des autres, le cherry-pick devient une chasse au trésor.

Le commit existe maintenant deux fois, avec deux identifiants. Quand dev sera fusionnée plus tard dans int, Git reconnaît en général que le changement est déjà là. Mais si le code a bougé entre-temps des deux côtés, attends-toi à un conflit sur ces lignes.

SourceDocumentation officielle : git-scm.com/docs/git-cherry-pick (options -x, plages de commits, --continue / --abort).

Le hotfix : réparer la prod sans embarquer dev

Un correctif urgent part de main, revient dans main — puis redescend dans les autres branches. Sinon, le bug revient à la prochaine mise en production.

La prod est cassée. Tu ne peux pas passer par dev : elle contient des features pas encore validées, qui partiraient avec ton correctif. Le correctif part donc de ce qui est en production, et y retourne directement.

git switch main
git pull
git switch -c hotfix/paiement-en-double

# … le correctif, un commit …
git push -u origin hotfix/paiement-en-double
# → pull request vers main, mise en production

# Puis faire redescendre le correctif (selon l'équipe : merge ou cherry-pick)
git switch dev
git pull
git cherry-pick -x 8d41c02        # ou : git merge origin/main
git push

La redescente est l'étape qu'on oublie. Le correctif est en prod, tout le monde souffle, personne ne le recopie dans dev et int. Trois semaines plus tard, dev monte en production… sans le correctif. Le bug revient, et cette fois on ne comprend pas pourquoi. En Git flow, c'est écrit dans la règle : une branche hotfix se fusionne dans main et dans develop.

Marquer une version : les tags

Un tag, c'est une étiquette qui ne bouge plus. « Ce qui est parti en production le 12 mars », c'est v1.4.0, pour toujours.

Une branche avance à chaque commit, un tag reste collé au sien. On en pose un à chaque mise en production ou à chaque version livrée. Le format le plus courant est vMAJEUR.MINEUR.CORRECTIF — la gestion sémantique de version : le correctif monte pour une réparation, le mineur pour une nouveauté, le majeur quand quelque chose casse pour ceux qui s'en servent.

git tag -a v1.4.0 -m "Version 1.4.0"   # poser un tag sur le commit courant
git push origin v1.4.0                  # les tags ne partent pas avec un simple push
git tag                                 # la liste
git switch --detach v1.3.2              # aller voir le code d'une ancienne version

Le dernier cas sert plus qu'on ne croit : un client signale un bug sur « la version d'avant », tu vas voir exactement ce code-là en une commande. Tu es alors « détaché » de toute branche : pour corriger, crée une branche à cet endroit avec git switch -c.

Sourcesemver.org, « Gestion sémantique de version ». Tags : Pro Git, « Étiquetage ».

Ton premier jour dans une équipe : huit questions

Le workflow ne se devine pas. Il se demande — ou se lit dans l'historique et le README avant de demander.

De quelle branche part une nouvelle feature ? main, dev, develop ?
Comment on nomme les branches ? feature/JIRA-123-panier, feat/panier, prenom/panier…
Y a-t-il un format pour les messages de commit ? Numéro de ticket, feat: / fix:…
Merge, rebase ou squash au moment de fusionner une pull request ?
Pour me remettre à jour : rebase de ma branche, ou merge de la base dedans ?
Qui fait monter dev vers int puis vers main, et quand ? Un jour fixe, la CI, le lead ?
Quelles branches sont protégées ? Où ai-je le droit de pousser directement ?
Comment on fait un hotfix, et qui fait redescendre le correctif ?

La moitié des réponses se lit avant même de demander :

git branch -r                           # les branches qui existent sur le serveur
git log --oneline --graph --all -30     # la forme de l'historique : droit ou en losanges ?
git log origin/main --oneline -15       # des commits de fusion ? un commit par PR ?

Les 7 pièges

Ce que tout le monde fait au moins une fois, et ce qu'il faut faire à la place.

1
« git add . et on verra ». C'est comme ça qu'un .env ou un dossier de build part sur le serveur. Nomme tes fichiers ou passe par git add -p, et écris le .gitignore avant le premier commit.
2
« Le push est refusé, je force ». Quelqu'un a poussé avant toi. git pull --rebase, puis git push. Forcer efface son travail.
3
« Je rebase dev, ce sera plus propre ». Branche partagée : tu réécris l'historique de toute l'équipe. On rebase seulement ses propres branches.
4
« J'ai fait un reset --hard, tout est perdu ». Ce qui avait été commité est dans le reflog. Ce qui ne l'était pas, non : c'est pour ça qu'on commite souvent.
5
« Je travaille directement sur main ». Une branche coûte une commande. Même seul sur un projet : une branche par sujet, et main reste toujours dans un état qui marche.
6
« Ma branche vit depuis trois semaines ». Plus elle vit, plus les conflits grossissent. Rebase sur la base tous les jours, et des pull requests assez petites pour être relues en un quart d'heure.
7
« J'ai supprimé le fichier avec le secret, c'est réglé ». Il reste dans l'historique, et quelqu'un a peut-être déjà cloné. Change le secret, tout de suite.

L'antisèche

Toute la page en une vue, rangée par situation. À garder ouverte dans un onglet.

Démarrer

git clone <url>: récupérer un projet existant
git init: transformer un dossier en dépôt
git remote add origin <url>: relier le dépôt à un serveur
git config --global user.email …: dire qui tu es, une fois par machine

Tous les jours

git status: où j'en suis
git diff / git diff --staged: ce qui a changé / ce qui va partir
git add -p: choisir morceau par morceau
git commit -m "…": prendre la photo
git log --oneline --graph: l'historique lisible

Le serveur

git fetch: regarder sans toucher
git pull --rebase: récupérer et rejouer mes commits par-dessus
git push -u origin <branche>: premier envoi d'une branche
git push --force-with-lease: après un rebase, sur ma branche seulement

Les branches

git switch -c <branche>: créer et y aller
git switch <branche>: changer de branche
git merge <branche>: fusionner dans la branche courante
git branch -d <branche>: supprimer une branche fusionnée

Le rebase

git rebase origin/main: remettre ma branche au bout de main
git rebase -i origin/main: nettoyer mes commits avant la PR
git rebase --continue / --abort: après un conflit / tout annuler
git commit --fixup <hash>: corriger un commit précis, rangé par --autosquash

Réparer

git restore <fichier>: annuler mes modifs sur un fichier
git commit --amend: refaire le dernier commit
git reset --soft HEAD~1: défaire le dernier commit, garder le travail
git revert <hash>: annuler un commit déjà poussé
git stash / git stash pop: mettre de côté / reprendre
git reflog: retrouver l'état d'avant la bêtise

En équipe

git cherry-pick -x <hash>: recopier un commit sur la branche courante
git cherry-pick -x A^..B: une série de commits, A et B inclus
git tag -a v1.4.0 -m "…": marquer une version
git push origin v1.4.0: envoyer le tag

Les autres ressources

Gratuites, en français, sans email à donner.