Quelles commandes Git faut-il vraiment connaître ?

Résumer ce contenu avec :

Perplexity ChatGPT Claude Grok Mistral

Les commandes Git à connaître sont celles qui sécurisent votre code, clarifient votre historique et évitent les galères d’équipe. Je vous montre celles que j’utilise vraiment au quotidien, avec les bons réflexes modernes comme git switch et git restore.

Pourquoi Git reste indispensable ?

Git reste indispensable parce qu’il garde une trace fiable de chaque évolution du code. Même avec l’IA, le low code, les notebooks cloud et les plateformes qui promettent de tout simplifier, j’ai encore besoin d’un endroit propre pour savoir ce qui a changé, quand, pourquoi, et par qui.

Je le vois souvent sur des projets data ou automatisation. Une personne modifie un script Python, une autre ajuste une requête SQL, quelqu’un touche une config Make ou n8n, et un notebook part dans une nouvelle direction. Sans Git, on finit avec des fichiers “final_v2_bon_celui_la.ipynb”. Et là, bon courage.

Programmation

Le vibe coding est-il fiable pour coder plus vite ?

septembre 21, 2026

Git permet de travailler sans peur. Je peux tester une idée, casser un bout de code, revenir en arrière, comparer deux versions, garder plusieurs pistes en parallèle avec des branches, puis envoyer mon travail vers un dépôt distant comme GitHub, GitLab ou Bitbucket. Un dépôt distant, c’est simplement une version partagée du projet, accessible à l’équipe et souvent connectée aux outils de déploiement.

Les commandes à connaître tournent autour de quelques besoins simples. Pas besoin de tout apprendre d’un coup. Il faut surtout comprendre les familles :

• Créer ou récupérer un projet avec git init ou git clone.
• Voir où on en est avec git status.
• Préparer et enregistrer des changements avec git add et git commit.
• Travailler sur plusieurs versions avec git branch et git switch.
• Revenir sur une modification avec git restore.
• Assembler ou réorganiser le travail avec git merge et git rebase.
• Envoyer son travail vers le dépôt distant avec git push.

Sur le terrain, les vrais problèmes ne viennent pas souvent de Git lui-même. Ils viennent plutôt d’un usage flou. Des commits qui disent juste “update”. Des branches ouvertes depuis trois mois. Des changements mélangés dans un seul gros commit impossible à relire. Git est carré, mais il ne compense pas une équipe qui ne se met pas d’accord sur une façon simple de travailler.

Comment démarrer un dépôt Git ?

Programmation

Comment mieux coder avec Claude Code sans perdre de temps ?

septembre 21, 2026

Pour démarrer un dépôt Git, j’utilise soit git init pour partir d’un dossier local, soit git clone pour récupérer un projet distant. La différence est simple. Avec git init, je transforme un dossier existant en dépôt Git. Avec git clone, je copie un dépôt qui existe déjà ailleurs, avec son code et son historique.

Quand je pars d’un projet vide ou d’un dossier que j’ai déjà sur ma machine, je fais ça.

# Créer un dossier pour le projet
mkdir mon-projet

# Entrer dans le dossier
cd mon-projet

# Initialiser Git dans ce dossier
git init

# Vérifier l’état du dépôt
git status

À ce moment-là, Git crée sa structure interne dans un dossier caché appelé .git. C’est là qu’il stocke les informations du dépôt, les commits, les branches, bref tout ce qui permet de suivre l’historique. Attention à un point bête, mais classique chez mes clients aussi : Git suit ce dossier et tout ce qu’il y a dessous. Donc si je lance git init trop haut, par exemple dans mon dossier Documents, je me retrouve vite avec un bazar inutile.

Programmation

Comment installer Python sur Windows facilement ?

septembre 21, 2026

Quand le projet existe déjà sur une plateforme distante, je ne fais pas git init. Je clone.

# Cloner un dépôt distant
git clone https://exemple.com/organisation/projet.git

# Entrer dans le dossier cloné
cd projet

# Vérifier l’état du dépôt
git status

Le clone récupère le code, l’historique Git, les branches utiles, et les infos du dépôt distant. C’est pour ça qu’après un clone, je peux souvent pousser mes changements sans rien configurer de plus.

Pour vérifier ce lien avec le dépôt distant, j’utilise git remote. Le nom le plus courant du dépôt distant, c’est origin. Ce n’est pas magique, c’est juste une convention.

# Voir les dépôts distants configurés
git remote -v

# Lier un dépôt local à un dépôt distant
git remote add origin https://exemple.com/organisation/projet.git

# Vérifier que le remote est bien configuré
git remote -v

Programmation

Comment faire l’orchestration de ressources Python ?

septembre 21, 2026

Les erreurs fréquentes sont presque toujours les mêmes.

• Initialiser Git au mauvais niveau de dossier, puis suivre trop de fichiers.
• Cloner dans un dossier déjà rempli, alors que git clone crée déjà son propre dossier.
• Oublier de vérifier git remote -v avant de pousser, puis envoyer le code au mauvais endroit.

Comment enregistrer proprement ses changements ?

Pour enregistrer proprement mes changements, je vérifie l’état du dépôt avec git status, je prépare les bons fichiers avec git add, puis je crée un commit lisible avec git commit. C’est vraiment le trio de base. Simple, mais ça évite beaucoup de dégâts.

Git status, c’est ma commande réflexe. Avant d’ajouter, avant de commit, parfois même avant de changer de branche. Elle me dit quels fichiers sont modifiés, ajoutés, supprimés, suivis par Git ou non suivis. Je préfère perdre 5 secondes avec git status plutôt que 30 minutes à comprendre ce que j’ai envoyé par erreur.

Git diff sert à relire ce qui a changé dans le code. C’est le moment où je vérifie si j’ai laissé un console.log, une clé API, un test temporaire, ou une modification qui n’a rien à faire dans ce commit. Chez un client, j’ai déjà vu un commit partir avec un fichier de configuration local juste parce que personne n’avait relu le diff. Classique, et franchement évitable.

Ces commandes me donnent une vision claire avant d’enregistrer quoi que ce soit.

# Vérifier l’état du dépôt
git status

# Voir les changements non encore préparés
git diff

Git add prépare les fichiers pour le prochain commit. Ajouter un fichier précis, c’est propre. Ajouter tout avec git add ., c’est pratique, mais je l’évite en automatique quand je ne sais pas exactement ce qui a changé.

# Ajouter un fichier précis
git add fichier.py

# Ajouter toutes les modifications du dossier courant
git add .

Git commit, lui, crée un point de sauvegarde logique. Pas une poubelle à modifications. Un bon commit raconte une intention courte et claire. Par exemple : “Ajoute la validation des emails”, “Corrige le calcul du total panier”, “Supprime l’ancien connecteur Stripe”. Les messages comme “update”, “fix” ou “test” ne servent à rien quand je reviens trois semaines plus tard.

# Créer un commit avec un message clair
git commit -m 'Corrige le calcul du total panier'

# Afficher l’historique en version compacte
git log --oneline

Comment travailler avec des branches ?

Pour travailler avec des branches, je crée une branche dédiée, je bascule dessus avec git switch, puis je fusionne le travail seulement quand il est prêt. Une branche, c’est juste une ligne de travail séparée. Je peux tester une idée, corriger un bug, développer une fonctionnalité, sans mettre le bazar dans la branche principale, souvent main.

Dans la vraie vie, c’est ce qui évite les sueurs froides. J’ai déjà vu des équipes tout faire directement sur main, puis passer deux heures à comprendre pourquoi l’app ne démarrait plus. Une branche aurait évité ça.

La commande git branch sert à voir, créer et supprimer des branches. Elle ne change pas forcément de branche, elle gère surtout la liste.

git branch
# Liste les branches locales du projet

git branch nouvelle-fonction
# Crée une branche appelée nouvelle-fonction, sans basculer dessus

git branch -d ancienne-branche
# Supprime une branche locale déjà fusionnée

Je fais attention à ne pas garder des branches mortes pendant des semaines. Au début, ça paraît anodin. Puis on se retrouve avec quinze branches dont personne ne connaît l’état. Ça pollue le projet, ça ralentit les décisions, et ça donne envie de ne plus rien toucher.

Pour changer de branche, j’utilise aujourd’hui git switch. C’est la commande moderne recommandée par Git pour ce cas précis.

git switch main
# Bascule sur la branche main

git switch -c feature-tracking
# Crée la branche feature-tracking et bascule dessus directement

Avant, on faisait beaucoup de choses avec git checkout. Il existe toujours, et vous allez le voir dans plein de tutos et de vieux projets. Le souci, c’est qu’il peut à la fois changer de branche et restaurer des fichiers. Pour un nouveau workflow, c’est moins clair.

git checkout ancienne-branche
# Ancienne manière de basculer sur une branche

Git a séparé les usages pour rendre les choses plus lisibles. Git switch pour changer de branche. Git restore pour restaurer des fichiers.

Git restore sert à annuler des modifications locales sur un fichier, ou à restaurer un fichier depuis l’index. L’index, c’est la zone de préparation, celle où vont les fichiers après git add et avant git commit.

git restore fichier.py
# Annule les modifications locales non commités sur fichier.py

Je le dis franchement : git restore peut supprimer du travail non commité. Donc avant de l’utiliser, je fais toujours un git status. Et si j’ai le moindre doute, je copie le bout de code que je ne veux pas perdre dans un fichier temporaire. Ce n’est pas élégant, mais ça sauve des journées.

Comment synchroniser et réorganiser son historique ?

Pour synchroniser et réorganiser mon historique, j’utilise git fetch, git pull, git push, git merge et git rebase selon le niveau de contrôle dont j’ai besoin. Le piège classique, c’est de les mélanger. Je le vois souvent chez des clients : quelqu’un fait un push en pensant sauvegarder son travail, sauf que ses fichiers modifiés ne sont même pas commités. Git push n’envoie pas des fichiers “en vrac”. Il envoie des commits.

Git push, c’est l’envoi de mes commits locaux vers le dépôt distant, souvent GitHub, GitLab ou Bitbucket.

# Envoyer mes commits locaux vers la branche main du dépôt distant origin
git push origin main

# Premier push d’une branche locale, avec suivi automatique du distant
git push -u origin main

Git fetch, lui, récupère les infos du dépôt distant sans toucher directement à ma branche locale. C’est pratique quand je veux regarder ce qui a changé avant d’intégrer. Git pull, c’est plus direct : il fait un fetch, puis il intègre les changements dans ma branche courante.

# Récupérer les informations du distant sans modifier ma branche actuelle
git fetch origin

# Récupérer et intégrer directement la branche main distante
git pull origin main

Git merge sert à fusionner une branche dans une autre. Par exemple, j’ai terminé une branche feature-tracking, je reviens sur main, puis je fusionne.

# Revenir sur la branche principale
git checkout main

# Fusionner la branche feature-tracking dans main
git merge feature-tracking

Un conflit arrive quand Git ne sait pas choisir entre deux modifications au même endroit. Là, il s’arrête, il me montre le fichier concerné, et c’est à moi de trancher. Ce n’est pas grave, c’est juste Git qui refuse d’inventer une décision à ma place.

Git rebase, c’est différent. Il rejoue mes commits sur une autre base, souvent pour obtenir un historique plus linéaire, plus propre à lire.

# Rejouer mes commits de branche courante au-dessus de main
git rebase main

Je fais attention avec rebase. Si les commits ont déjà été partagés avec d’autres, je ne rebase pas sans coordination. Ça réécrit l’historique, et ça peut créer un beau bazar.

Quand je dois changer de contexte sans finir mon travail, j’utilise git stash. Quand je dois corriger mon dernier commit, j’utilise parfois git reset, mais avec prudence. Et quand une version est stable, je la marque avec git tag.

# Mettre de côté un travail non terminé
git stash

# Récupérer le travail mis de côté
git stash pop

# Annuler le dernier commit en gardant les changements prêts à recommiter
git reset --soft HEAD~1

# Marquer une version du projet
git tag v1.0.0

Alors, quelles commandes Git faut-il garder sous la main ?

Je garderais surtout cette idée : Git devient simple quand on arrête de tout mélanger. git status pour voir clair, git add et git commit pour enregistrer proprement, git branch et git switch pour travailler sans casser le reste, git merge ou git rebase pour intégrer intelligemment, git push pour partager. Le reste vient avec la pratique. Dans les équipes que j’accompagne, le vrai gain arrive quand les commits sont lisibles et les workflows simples. Vous perdez moins de temps, vous cassez moins de choses, et votre code devient beaucoup plus facile à maintenir.

FAQ

• Quelles sont les commandes Git les plus importantes pour débuter ?
  Je commencerais avec git init, git clone, git status, git add, git commit, git log, git branch, git switch, git restore, git merge et git push. Avec ça, vous avez déjà la base pour créer un dépôt, suivre vos changements, travailler sur une branche et partager votre code.
• Quelle différence entre git add et git commit ?
  git add prépare les fichiers à enregistrer. git commit crée l’enregistrement dans l’historique. Dit autrement, git add sélectionne ce que vous voulez mettre dans la photo, git commit prend la photo.
• Faut-il encore utiliser git checkout ?
  git checkout existe toujours et vous le verrez partout. Mais pour un usage plus clair, je préfère git switch pour changer de branche et git restore pour restaurer des fichiers. Ça évite de confondre deux actions très différentes.
• Quelle différence entre git merge et git rebase ?
  git merge fusionne deux historiques et garde une trace claire de cette fusion. git rebase rejoue vos commits sur une autre base pour obtenir un historique plus linéaire. Le rebase est pratique, mais je l’utilise avec prudence sur du travail déjà partagé.
• Pourquoi mes messages de commit sont importants ?
  Parce qu’un bon message de commit explique ce qui a changé et pourquoi. Quand il faut corriger un bug, relire une évolution ou comprendre une décision trois semaines plus tard, des messages comme fix ou update ne servent presque à rien.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres clients sur des sujets très concrets : data fiable, automatisations solides, workflows propres et outils bien utilisés. Si vous voulez structurer vos projets data, IA ou automatisation sans empiler du bricolage, contactez-moi.

Franck Scandolera

⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA  ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.