Git pour les nouveaux : Domptez le dragon 🐉 sans brûler 🔥 le projet

Un guide humble, écrit par quelqu'un qui a déjà tout cassé au moins une fois.

Le programme

On avance doucement : chaque étape s'appuie sur la précédente.

01 — C'est quoi ce fameux Git ?

C'est votre machine à remonter le temps.

Créé par Linus Torvalds en 2005 (merci Linus !), c'est l'outil indispensable pour ne plus avoir de fichiers index_final_v2_copie.html.

Git ne sauvegarde pas des fichiers : il photographie votre projet, encore et encore.

Pourquoi on ne peut plus s'en passer

• Équipe : on travaille tous ensemble sans s'écraser les pieds.
• Sécurité : si on casse tout, on peut revenir en arrière.
• Liberté : on peut tester des trucs fous dans son coin (les branches !).
• Traçabilité : chaque changement a un auteur, une date et une raison.

Un peu d'histoire (pour la culture)

timeline
    title Du chaos à Git
    Avant 2005 : CVS, SVN : un serveur central, et la galère
    2005 : Le noyau Linux a besoin d'un outil plus solide
         : Naissance de Git en quelques semaines
    2008 : GitHub arrive
    Aujourd'hui : GitLab, Bitbucket, Forgejo : Git est partout

Git ne se limite pas à GitHub

Git fonctionne très bien sans réseau. Le partage vient après.

Première configuration

À faire une seule fois par machine :

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

Pour vérifier :

git config --list

Ce nom et cet email seront inscrits dans chacun de vos commits.

Démarrer un projet

Deux façons de commencer :

# 1. Partir de zéro dans un dossier
git init

# 2. Récupérer un projet existant
git clone https://github.com/equipe/projet.git

Après git init, un dossier caché .git apparaît : c'est la mémoire du projet. Ne le supprimez pas.

Comprendre le "Graphe"

La structure de base

gitGraph
    commit id: "Initial"
    branch develop
    checkout develop
    commit id: "Feature A"
    commit id: "Feature B"
    checkout main
    merge develop
    commit id: "Merge feature"

Les mots qu'on utilise souvent

Les trois zones de Git

flowchart LR
    A[Working directory<br/>vos fichiers] -->|git add| B[Staging area<br/>la valise prête]
    B -->|git commit| C[Dépôt local<br/>l'historique]
    C -->|git push| D[(Remote<br/>GitHub)]
    D -->|git pull| A

Si vous retenez un seul schéma de cette présentation, c'est celui-ci.

Le workflow quotidien

C'est simple, on suit ce cycle :

1. Modified : on change le code.
2. Staged (git add) : on prépare ce qu'on veut envoyer.
3. Committed (git commit) : on valide dans notre historique local.
4. Pushed (git push) : on partage avec les copains.

02 — Mes commandes favorites

# Pour savoir où on en est (ma préférée)
git status

# Pour préparer le terrain
git add .

# Pour immortaliser le moment
git commit -m "feat: ajout d'une super fonction"

# Pour voir ce qu'on a fait
git log --oneline

Un cycle complet, en vrai

$ git status
Changes not staged for commit:
        modified:   index.html

$ git add index.html
$ git commit -m "fix: corrige le titre de la page"
[main 3f9a1c2] fix: corrige le titre de la page
 1 file changed, 1 insertion(+), 1 deletion(-)

Regarder avant de valider

# Ce que j'ai modifié (pas encore ajouté)
git diff

# Ce que je m'apprête à commiter
git diff --staged

# L'historique, en version lisible
git log --oneline --graph --all

Prenez l'habitude : git status, puis git diff, puis git commit.

Ajouter avec précision

git add -p est un petit trésor pour faire des commits propres.

Ignorer ce qui ne doit pas être suivi

Le fichier .gitignore liste ce que Git doit laisser tranquille :

node_modules/
.env
dist/
*.log
.DS_Store

Ne commitez jamais de mots de passe ou de clés (.env). Même supprimés après coup, ils restent dans l'historique.

03 — Les branches : des univers parallèles

Une branche, c'est juste un pointeur léger vers un commit. Elle ne coûte presque rien : créez-en sans compter.

# Voir les branches
git branch

# Créer et s'y déplacer
git switch -c feature/login

# Revenir sur main
git switch main

Le cycle d'une feature

gitGraph
    commit id: "Départ"
    branch feature/login
    checkout feature/login
    commit id: "Formulaire"
    commit id: "Validation"
    checkout main
    commit id: "Hotfix"
    merge feature/login

Pendant que vous travaillez sur feature/login, main reste intact.

Merge : on rassemble les univers

git switch main
git merge feature/login

Deux cas possibles :

• Fast-forward : main n'a pas bougé, Git avance simplement le pointeur.
• Merge commit : les deux branches ont évolué, Git crée un commit qui les réunit.

Une fois fusionnée, on range :

git branch -d feature/login

Zen face aux conflits

Ça arrive même aux meilleurs (et surtout à moi après 15 ans).

<<<<<<< HEAD
Votre super code
=======
Le code du collègue (qui est pas mal aussi)
>>>>>>> branch-name

La recette anti-panique

1. 🧘 On respire. Un conflit n'est pas une erreur, c'est une question.
2. 🔎 git status liste les fichiers concernés.
3. ✏️ On édite : on garde le meilleur des deux et on supprime les marqueurs <<<<<<<, =======, >>>>>>>.
4. ➕ git add fichier pour dire "c'est réglé".
5. ✅ git commit pour conclure le merge.

Pas sûr de vous ? git merge --abort remet tout comme avant.

04 — Travailler à plusieurs

sequenceDiagram
    participant Vous
    participant Remote as GitHub
    participant Collegue as Collègue
    Collegue->>Remote: git push
    Vous->>Remote: git pull
    Remote-->>Vous: les nouveaux commits
    Vous->>Remote: git push

Les commandes du partage

# Premier push d'une nouvelle branche
git push -u origin feature/login

Le flux d'une Pull Request

flowchart LR
    A[Créer une branche] --> B[Commiter]
    B --> C[Push]
    C --> D[Ouvrir la Pull Request]
    D --> E{Relecture}
    E -->|Demande de changements| B
    E -->|Approuvée| F[Merge dans main]

Une Pull Request, c'est surtout une conversation : on apprend beaucoup en relisant et en étant relu.

Les bonnes manières

• Commitez souvent : des petits changements valent mieux qu'un énorme bloc.
• Messages clairs : vos collègues (et votre futur "vous") vous remercieront.
• Relisez-vous : une petite vérification avant le push, ça ne mange pas de pain.
• Tirez avant de pousser : git pull évite bien des surprises.

Des messages qui parlent

On utilise un préfixe pour dire de quoi il s'agit (Conventional Commits) :

05 — Les commandes de secours

(quand ça part en vrille)

Respirez : Git garde presque tout. Voici la trousse de premiers secours, du plus doux au plus costaud.

Stash : mettre de côté

Vous êtes en plein travail et on vous demande un correctif urgent ?

git stash            # on range le travail en cours
git switch main      # on va faire le correctif
# ... correctif, commit, push ...
git switch feature/login
git stash pop        # on retrouve son travail

Corriger le dernier commit

Oups, un fichier oublié ou une faute dans le message :

git add fichier-oublie.txt
git commit --amend -m "feat: ajout du login (complet cette fois)"

--amend remplace le dernier commit. À réserver aux commits pas encore poussés.

Reset : la machine à voyager dans le temps

Parfois, on fait des commits... disons, "pas top". Reset est notre machine à remonter le temps.

gitGraph
    commit id: "Commit A"
    commit id: "Commit B (pas top)"
    commit id: "Commit C (pire)"
    commit id: "Commit D (catastrophe)"

Les 3 saveurs de reset

En commandes

git reset --soft HEAD~1   # Revient d'un commit, tout est prêt à re-commiter
git reset HEAD~1          # Revient d'un commit, changements à re-ajouter
git reset --hard HEAD~1   # Revient d'un commit, tout disparaît

HEAD~1 veut dire "un commit avant celui où je suis".

Reset en pratique

Vous avez fait un mauvais commit en local, pas encore poussé :

git reset --soft HEAD~1   # on défait le commit, on garde le travail
# on corrige ce qui ne va pas
git add .
git commit -m "feat: version propre"

--hard est le seul qui détruit votre travail. Dans le doute, prenez --soft.

Revert : l'annulation propre

Quand on veut annuler un commit sans toucher à l'historique (super pour les projets partagés).

Revert en action

gitGraph
    commit id: "Commit A"
    commit id: "Commit B (à annuler)"
    commit id: "Commit C"
    commit id: "Revert de B"

git revert commitSHA  # Crée un commit qui annule les changements

Reflog : le filet de sécurité

Même après un reset --hard, Git se souvient de là où vous étiez.

git reflog

3f9a1c2 HEAD@{0}: reset: moving to HEAD~1
a81b7d4 HEAD@{1}: commit: feat: ma super fonction

git reset --hard a81b7d4   # on revient avant la bêtise

Le reflog garde la trace pendant plusieurs semaines. C'est la réponse à "j'ai tout perdu !".

06 — Rebase : la magie du réaménagement

Rebase permet de réorganiser l'historique pour le rendre plus propre.

Merge ou rebase ?

Avec merge : on garde l'historique exact, avec un commit de fusion.

gitGraph
    commit id: "Initial"
    branch feature
    commit id: "Feature 1"
    commit id: "Feature 2"
    checkout main
    commit id: "Fix urgent"
    merge feature

Avec rebase : on déplace nos commits après le fix urgent. L'historique devient une ligne droite.

gitGraph
    commit id: "Initial"
    commit id: "Fix urgent"
    commit id: "Feature 1'"
    commit id: "Feature 2'"

git switch feature
git rebase main

Rebase interactif : le mode "je suis le chef"

git rebase -i HEAD~3  # 3 derniers commits

Les options magiques :

Rebase interactif en pratique

Avant : un historique de brouillon.

flowchart LR
    A[WIP: début] --> B[fix: typo]
    B --> C[WIP: suite]
    C --> D[feat: presque fini]
    D --> E[fix: autre typo]

Après squash + reword : un seul commit lisible.

flowchart LR
    A[feat: fonctionnalité complète]

Ce qu'on écrit dans l'éditeur

pick 1234abcd WIP: début
squash 5678efgh fix: typo
squash 9012ijkl WIP: suite
squash 3456mnop feat: presque fini
squash 7890qrst fix: autre typo

Devient, après sauvegarde et nouveau message :

pick 1234abcd feat: fonctionnalité complète

Les règles d'or du rebase

Pourquoi ? Parce que rebase réécrit l'historique. Si quelqu'un a déjà tiré vos commits, ça va être le chaos !

Deux petits bonus

Cherry-pick : piquer un seul commit

git cherry-pick commitSHA

Utile pour récupérer un correctif d'une autre branche sans tout fusionner.

Tag : poser un jalon

git tag v1.0.0
git push origin v1.0.0

Pratique pour marquer les versions livrées.

Schéma récapitulatif

flowchart TD
    A[Problème à résoudre] --> B{Est-ce partagé ?}
    B -->|Non| C[Rebase possible]
    B -->|Oui| D[Revert obligatoire]
    C --> E{Type de correction ?}
    E -->|Annuler tout| F[git reset --hard]
    E -->|Garder changements| G[git reset --soft]
    E -->|Nettoyer historique| H[git rebase -i]
    D --> I[git revert commitSHA]
    F --> J[Historique réécrit]
    G --> K[Changements dans staging]
    H --> L[Historique propre]
    I --> M[Nouveau commit d'annulation]

L'aide-mémoire

Votre feuille de route

• Comprendre les trois zones
• Maîtriser add, commit, status, log
• Créer des branches et les fusionner
• Résoudre un conflit sans paniquer
• Utiliser reset, revert et reflog
• Nettoyer son historique avec rebase -i
• Faire sa première Pull Request

Allez, à vous de jouer

N'ayez pas peur de casser des trucs sur des projets de test. C'est comme ça qu'on apprend. Et rappelez-vous : on est tous passés par là !

Bon code à tous ! 🚀