Git pour débutants : workflow simple (status, add, commit) + annuler sans risque
Guides

Git pour débutants : workflow simple (status, add, commit) + annuler sans risque

Antharuu Antharuu
9 min de lecture
Debutant Bonnes pratiques Programmation Git

Git, c’est un peu le “filet de sécurité” de vos projets (code, documents, notes…), mais en version vraiment solide : ça garde un historique clair de tout ce qui change, et ça vous permet de revenir en arrière quand vous le voulez. Et accrochez-vous, parce qu’au début ça a l’air un peu “terminal et magie noire”… mais en vrai, c’est surtout une routine simple : regarder → préparer → sauvegarder.

Dans ce guide, on se concentre sur Git en local (sur votre ordinateur). GitHub/GitLab, c’est la partie “en ligne” (pratique, mais pas obligatoire pour démarrer). On va voir ça ensemble à la fin, tranquillement.

1) Git, c’est quoi exactement (et pourquoi tout le monde l’utilise) ?

Git, c’est un outil de gestion de versions. Dit autrement : c’est un système qui enregistre l’évolution de vos fichiers dans le temps.

Sans Git, votre projet finit souvent comme ça :

  • mon-projet-final
  • mon-projet-final-v2
  • mon-projet-final-v2-cettefois-cest-la-bonne (et là, vous vous demandez peut-être : “mais j’étais où, avant de tout casser ?”)

Avec Git :

  • vous faites des sauvegardes intelligentes appelées commits,
  • vous pouvez comparer ce qui a changé,
  • vous pouvez revenir à une version précédente,
  • vous pouvez travailler sur plusieurs idées en parallèle avec des branches,
  • et c’est distribué : tout l’historique est chez vous, même sans internet (c’est top, non ?).

Exemple concret : vous faites un petit site.

  • Commit 1 : “page d’accueil”
  • Commit 2 : “ajout du menu”
  • Commit 3 : “correction du CSS” Et si le menu a tout cassé… vous revenez à avant (sans pleurer).

2) Installer Git (Windows / macOS / Linux)

Git, c’est gratuit, et ça tourne sur Windows, macOS et Linux. Le plus simple, c’est de passer par le site officiel : git-scm.com.

Linux (Ubuntu / Debian)

Ouvrez un terminal et tapez :

sudo apt update
sudo apt install git
git --version

macOS (avec Homebrew)

Si vous avez Homebrew :

brew install git
git --version

Si Homebrew n’est pas installé, vous pouvez l’installer via la commande donnée sur brew.sh (oui, c’est un peu long, mais c’est du “copier-coller et attendre”).

Windows

  • Téléchargez l’installateur sur git-scm.com
  • Gardez les options par défaut (au début, c’est le plus simple)
  • Utilisez Git Bash (installé avec Git), c’est un terminal “friendly” pour démarrer

Mini-parenthèse : un terminal, c’est une fenêtre où vous tapez des commandes. C’est impressionnant 30 secondes (puis ça devient juste… pratique).

3) Configuration initiale (à faire une seule fois)

Git doit savoir “qui” fait les commits. Ce n’est pas pour vous espionner, c’est juste pour signer l’historique.

git config --global user.name "Votre Nom"
git config --global user.email "votre.email@example.com"
git config --list
  • --global, c’est “pour tous mes projets”
  • git config --list, c’est la vérification (toujours rassurant)

4) Comprendre les 3 zones de Git (le truc qui débloque tout)

Git, ce n’est pas juste “j’enregistre”. C’est un flux en 3 étapes, et c’est ça qui rend Git puissant (et parfois déroutant au début).

Les 3 zones

  • Dossier de travail (working directory) : vos fichiers tels qu’ils sont sur votre disque (là où vous éditez)
  • Index / Staging area : une zone de préparation (comme un panier avant de payer)
  • Dépôt (repository) / Historique : là où vivent les commits (les versions sauvegardées)

Et HEAD, c’est un pointeur vers “là où vous êtes” dans l’historique (en général, le dernier commit de votre branche).

Le workflow simple (à répéter tout le temps)

  1. Je regarde : git status
  2. Je prépare : git add ...
  3. Je sauvegarde : git commit -m "message"

Voilà. C’est basique, mais c’est la colonne vertébrale.

5) Créer un dépôt Git (un nouveau projet)

On part sur un exemple : un dossier mon-site.

1) Créer le dossier et entrer dedans

mkdir mon-site
cd mon-site

2) Initialiser Git

git init

Ça crée un dossier caché .git. Et là, règle d’or : on ne bidouille pas .git (Git s’en occupe très bien tout seul).

3) Créer un premier fichier

Par exemple :

echo "Hello Git !" > index.html

4) Vérifier l’état

git status

Vous verrez votre fichier “non suivi” (untracked). C’est normal : Git ne versionne pas tout automatiquement, il attend que vous lui disiez quoi suivre.

6) Faire votre premier commit (la première “sauvegarde”)

1) Ajouter au staging (au panier)

Pour un seul fichier :

git add index.html

Pour tout ajouter (pratique, mais à utiliser en conscience) :

git add .

Refaites :

git status

Normalement, c’est “en vert” (staged). C’est Git qui vous dit : “ok, prêt à être sauvegardé”.

2) Créer le commit

git commit -m "Ajout page d'accueil initiale"

Et là, c’est fait : vous avez une version enregistrée.

3) Voir l’historique

git log

Astuce : dans l’écran de log, appuyez sur q pour quitter.

Version courte :

git log --oneline

Routine typique ensuite : vous modifiez, vous git add, vous git commit. C’est simple, mais ça devient vite méga confortable.

7) Voir ce qui change et annuler (sans tout casser)

C’est souvent là que Git devient “votre assurance”.

Voir les différences (diff)

  • Avant add :
git diff
  • Comparer avec le commit précédent (exemple) :
git diff HEAD~1

Annuler proprement (les commandes safe)

Vous voulez “revenir en arrière”, mais selon où vous en êtes, ce n’est pas la même commande (eh oui, c’est un peu subtil, mais on va faire simple).

Cas A — Vous avez modifié un fichier, mais pas fait git add

Revenir à la version du dernier commit :

git restore index.html

Cas B — Vous avez fait git add, mais pas encore commit

Retirer du staging (sans perdre la modification dans le fichier) :

git restore --staged index.html

Ensuite, si besoin, vous pouvez aussi faire git restore index.html pour annuler vraiment.

Attention avec git reset

git reset, c’est utile, mais c’est plus “tranchant” (ça peut faire perdre des changements si on ne sait pas ce qu’on fait). Pour débuter, ce n’est pas interdit, mais ce n’est pas le premier outil à dégainer.

8) Les branches : tester des idées sans casser le projet principal

Une branche, c’est une “ligne de travail parallèle”. Et c’est justement ça qui rend Git génial : vous pouvez tenter un truc, et si c’est nul, vous revenez sur main comme si de rien n’était.

Voir sur quelle branche vous êtes

git branch

La branche courante est marquée (souvent avec un *).

Créer une branche et basculer dessus

Option moderne (recommandée) :

git switch -c nouvelle-fonction

Ou en version “ancienne” (toujours très courante) :

git branch nouvelle-fonction
git checkout nouvelle-fonction

Revenir sur main

git switch main

Fusionner une branche dans main

Vous vous placez sur main :

git switch main

Puis vous fusionnez :

git merge nouvelle-fonction

Et les conflits ?

Un conflit, c’est quand Git ne sait pas choisir automatiquement (genre vous avez modifié la même ligne dans deux branches). Ce n’est pas “grave”, mais c’est un petit moment où il faut décider. Git vous montre le fichier, vous corrigez, puis vous refaites un commit. (On pourrait y passer une heure, mais pour l’initiation, retenez juste : conflit = choix à faire, pas catastrophe.)

9) Cloner un dépôt existant (récupérer un projet déjà prêt)

Cloner, c’est copier un dépôt complet (fichiers + historique).

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

Et voilà : vous avez le projet en local, prêt à être lu, modifié, exploré.

10) Git en ligne (bonus) : GitHub / GitLab, c’est quoi et comment s’en servir

GitHub et GitLab, c’est des plateformes pour héberger des dépôts Git en ligne. En gros : Git est l’outil, GitHub/GitLab sont des “services autour”.

Ce que ça permet :

  • sauvegarde en ligne
  • collaboration
  • revue de code (pull requests / merge requests)
  • automatisations (CI/CD), etc.

Lier un dépôt local à un dépôt en ligne

Ajouter un “remote” (une adresse de dépôt distant) :

git remote add origin https://github.com/votrecompte/mon-site.git

Envoyer la branche main pour la première fois :

git push -u origin main

Récupérer les mises à jour :

git pull

En équipe, le schéma le plus courant, c’est : branches → pull request → fusion. C’est un garde-fou (c’est pratique, mais on peut démarrer sans).

Cheat sheet (à garder sous la main)

Commande À quoi ça sert
git init Initialiser un dépôt dans un dossier
git clone URL Copier un dépôt existant
git status Voir l’état actuel (le réflexe n°1)
git add . Ajouter tous les changements au staging
git add fichier Ajouter un fichier au staging
git commit -m "Msg" Créer une sauvegarde (commit)
git log --oneline Historique en version courte
git diff Voir les changements non ajoutés
git restore fichier Annuler des modifs locales
git restore --staged fichier Retirer du staging
git branch Voir les branches
git switch -c nom Créer + changer de branche
git merge nom Fusionner une branche
git push Envoyer vers le dépôt distant
git pull Récupérer depuis le dépôt distant

Prochaines étapes (pour devenir à l’aise, vraiment)

Ce qui marche le mieux, c’est la pratique (genre 20 minutes, pas plus, mais régulièrement) :

  • créez un petit dossier projet
  • faites 3–4 commits
  • créez une branche, modifiez un fichier, mergez
  • entraînez-vous à annuler (restore, restore --staged)
  • et quand vous êtes à l’aise : connectez GitHub/GitLab et faites un push

Et si vous êtes bloqué… vous allez rire, mais git status, c’est souvent la réponse. Git vous dit presque toujours quoi faire (il est bavard, et pour une fois, c’est une qualité).

Articles similaires