Maîtriser Git et GitHub : le guide complet

Tout développeur, un jour, perd du code. Un fichier écrasé, une « amélioration » qui casse tout, une version qui marchait et qu’on n’arrive plus à reconstituer. Git met fin à ce cauchemar : c’est un système qui enregistre l’histoire complète de votre projet, autorise des expérimentations sans risque, et coordonne le travail de plusieurs personnes sur le même code. GitHub, lui, héberge ces projets et ajoute une couche de collaboration devenue le standard mondial. Ce guide pose les fondations conceptuelles — le quoi et le pourquoi — puis vous oriente vers six tutoriels pratiques qui vous feront tout construire de vos mains, du premier commit à la pull request.

🎯 Ce que ce parcours vous permettra de faire

• Placer n’importe quel projet sous contrôle de version et enregistrer un historique propre.
• Mener plusieurs lignes de travail en parallèle grâce aux branches, puis les réunir.
• Garder un historique lisible en choisissant entre fusion et rebasage à bon escient.
• Résoudre sans stress les conflits inévitables du travail en équipe.
• Contribuer à des projets sur GitHub via le cycle fork, pull request et revue de code.
• Réparer toute erreur — commit perdu, branche supprimée, mauvaise manipulation — sans paniquer.

Pourquoi le contrôle de version est-il indispensable ?

Un système de contrôle de version enregistre, au fil du temps, les modifications apportées à un ensemble de fichiers, de sorte que l’on puisse revenir à n’importe quel état antérieur, comparer deux versions, ou comprendre qui a changé quoi et pourquoi. Sans un tel outil, on bricole avec des dossiers nommés projet-v2, projet-final, projet-final-vraiment — une méthode qui s’effondre dès qu’on travaille à plusieurs ou que le projet grandit.

Historiquement, ces systèmes étaient centralisés : un serveur unique détenait l’historique, et chacun en empruntait une version de travail (c’était le modèle de Subversion, ou SVN). Le défaut est évident : si le serveur tombe ou que la connexion manque, plus rien ne fonctionne. Git appartient à la génération suivante, celle des systèmes distribués. Conçu en 2005 par Linus Torvalds pour gérer le développement du noyau Linux, Git donne à chaque développeur une copie intégrale de l’historique sur sa machine. On peut donc commiter, consulter l’historique, créer des branches et fusionner entièrement hors ligne ; la synchronisation avec les autres n’intervient que lorsqu’on choisit de partager. Cette architecture explique à la fois la rapidité de Git et sa robustesse.

Git n’est pas GitHub

La distinction mérite d’être martelée, car elle est la source de bien des malentendus. Git est le logiciel de contrôle de version qui s’exécute sur votre machine — un programme en ligne de commande, gratuit et libre, qui n’a besoin d’aucun compte. GitHub est un service en ligne qui héberge des dépôts Git et ajoute par-dessus des outils de collaboration : pull requests, revues de code, suivi des tickets, automatisations d’intégration continue. On peut utiliser Git seul, sans jamais toucher à GitHub ; et GitHub n’est pas le seul de son espèce — GitLab, Bitbucket et Gitea hébergent eux aussi des dépôts Git, avec des philosophies variées (Gitea, par exemple, s’auto-héberge facilement).

L’image qui aide : Git est le moteur, GitHub l’un des garages où l’on range et partage les véhicules. Les compétences Git que vous acquérez sont universelles ; la plateforme, elle, est interchangeable.

Installer Git et le configurer

Git s’installe en quelques minutes sur les trois grands systèmes : un installeur sur Windows (qui fournit aussi le terminal Git Bash), le gestionnaire de paquets ou les outils de ligne de commande sur macOS, et le gestionnaire de paquets de la distribution sur Linux. On vérifie la présence de Git, et l’on confirme une version récente — Git publie des versions mineures à un rythme soutenu, et toute version 2.23 ou ultérieure suffit pour disposer des commandes modernes comme git switch et git restore.

git --version

Vient ensuite la configuration minimale, à faire une seule fois. Git inscrit votre nom et votre adresse dans chaque commit ; on les déclare globalement, et l’on en profite pour fixer le nom de la branche initiale à main, désormais le standard.

git config --global user.name "Votre Nom"
git config --global user.email "vous@example.com"
git config --global init.defaultBranch main

Ces gestes fondateurs sont détaillés, avec leur vérification, dans le premier tutoriel du parcours ci-dessous.

Le modèle mental de Git : la clé de tout

La majorité des frustrations avec Git viennent d’un modèle mental flou. Quelques idées, une fois assimilées, rendent tout le reste limpide.

Les trois zones

Un fichier suivi par Git vit dans trois espaces. Le répertoire de travail contient vos fichiers réels, ceux que vous éditez. L’index (ou zone de préparation) est une antichambre où vous rassemblez ce qui composera le prochain commit. Le dépôt — le dossier caché .git — est la base de données des commits enregistrés. La commande git add copie une version du fichier vers l’index ; git commit grave l’index dans le dépôt. Cette séparation vous permet de composer des commits cohérents même au milieu d’un travail désordonné.

Les commits sont des instantanés

Contrairement à une intuition répandue, un commit Git n’est pas une liste de différences mais une photographie complète de tous les fichiers suivis à un instant donné. Chaque commit possède une empreinte unique — un identifiant SHA calculé sur son contenu — et pointe vers son ou ses commits parents. L’ensemble forme une chaîne, puis, dès qu’apparaissent des branches et des fusions, un graphe orienté acyclique (en anglais DAG) : les commits sont les nœuds, et chacun connaît ses ancêtres.

HEAD, branches et références

Une branche n’est qu’un pointeur léger et mobile vers un commit ; créer une branche ne copie rien, d’où l’instantanéité de l’opération. HEAD est un pointeur spécial qui indique « où vous êtes » — généralement la branche courante. Les étiquettes (tags) sont des pointeurs fixes, utiles pour marquer des versions publiées. Comprendre que branches, HEAD et tags ne sont que des références vers des commits démystifie instantanément des opérations qui semblent magiques, comme le changement de branche ou la récupération d’un commit perdu via le journal des références.

Branches et collaboration : la vue d’ensemble

Le travail par branches est le cœur de la puissance de Git. On isole chaque fonctionnalité ou correction sur sa propre branche, sans perturber la ligne principale, puis on l’y réintègre une fois prête. La réintégration se fait de deux manières complémentaires : la fusion (merge), qui relie les histoires en créant au besoin un commit de fusion, et le rebasage (rebase), qui rejoue les commits pour produire une ligne droite. À l’échelle d’une équipe, GitHub orchestre ce ballet via les pull requests : on propose une branche, l’équipe la relit et la discute, on l’améliore, puis on la fusionne. Ce rituel, simple en apparence, structure la quasi-totalité du développement logiciel moderne.

Fusion ou rebasage : la synthèse

La question « merge ou rebase ? » revient sans cesse. Le tableau suivant condense les arbitrages ; le tutoriel dédié les approfondit avec des exemples.

La règle d’or à ne jamais oublier : on rebase librement ses commits locaux, jamais un historique déjà partagé avec d’autres.

🗺️ Le parcours d’apprentissage

Les six tutoriels ci-dessous forment une progression cohérente. Ils construisent tous le même projet fil rouge — un dépôt nommé boutique-inventaire, petite application web de gestion de stock — afin que chaque notion s’ancre dans un contexte concret et continu. Suivez-les dans l’ordre si vous débutez ; piochez à la carte si vous consolidez un point précis.

1. Les bases de Git : init, add, commit et log — Le socle absolu : transformer un dossier en dépôt, comprendre les trois zones, enregistrer des versions propres et lire l’historique.
2. Branches Git et fusion — Créer des branches, travailler en parallèle, et fusionner en avance rapide ou à trois sources.
3. Rebase vs merge : un historique propre — Linéariser l’historique, nettoyer ses commits avec le rebasage interactif, et appliquer la règle d’or.
4. Résoudre les conflits de fusion — Lire les marqueurs, choisir la bonne version, finaliser ou annuler, et réduire la fréquence des conflits.
5. Workflow GitHub : fork, pull request et revue — Contribuer à un projet via le modèle fork plus pull request, et mener une revue de code.
6. Annuler et réparer : reset, revert, reflog, stash — La trousse de secours : défaire proprement, et récupérer ce qu’on croyait perdu.

Bonnes pratiques transversales

Quelques habitudes, valables quel que soit le sujet, distinguent un usage serein de Git d’un usage subi. La première est de faire des commits atomiques : chaque commit ne fait qu’une chose et la fait entièrement, ce qui rend l’historique compréhensible et un éventuel retour en arrière chirurgical. La deuxième est de soigner les messages de commit : une ligne de sujet courte à l’impératif, puis, au besoin, un paragraphe expliquant le pourquoi plutôt que le comment — le code dit déjà comment, le message doit dire pourquoi.

La troisième est de créer un fichier .gitignore dès le premier commit, pour ne jamais polluer l’historique avec des dépendances, des fichiers générés ou des secrets. La quatrième est de brancher tôt et fusionner souvent : des branches de courte durée, intégrées régulièrement, génèrent beaucoup moins de conflits que des branches géantes vivant des semaines en parallèle. La cinquième, enfin, est de synchroniser fréquemment avec la ligne principale et de ne jamais réécrire un historique déjà partagé. Ces réflexes, adoptés dès le départ, vous épargneront l’essentiel des difficultés rencontrées par ceux qui apprennent Git sur le tas.

Panorama des pièges classiques

Au-delà des erreurs propres à chaque sujet (détaillées dans les tutoriels), quelques pièges transversaux méritent une vigilance constante. Le premier est de réécrire un historique partagé : un rebasage ou un reset sur des commits déjà poussés casse le travail des collègues ; la parade est de réserver la réécriture au local et d’utiliser revert sur le partagé. Le deuxième est de commiter sur la mauvaise branche par oubli de basculement — récupérable via cherry-pick et reset. Le troisième est de commiter des fichiers indésirables (secrets, dépendances volumineuses), évité par un bon .gitignore dès le départ. Le quatrième est de paniquer après un reset --hard en croyant tout perdu, alors que le reflog garde la trace des commits pendant des semaines. Le cinquième, enfin, est de tenter de s’authentifier à GitHub par mot de passe, qui n’est plus accepté depuis le 13 août 2021 : il faut un jeton d’accès personnel ou une clé SSH.

Travailler avec des dépôts distants : le modèle mental

Dès que le travail se partage, Git introduit la notion de dépôt distant : une copie du dépôt hébergée ailleurs, sur un serveur ou une plateforme comme GitHub. Par convention, le distant principal se nomme origin. Trois opérations articulent les échanges. git fetch récupère les nouveautés du distant sans rien changer à votre travail : il met simplement à jour votre vision de l’état distant (les références origin/...). git pull enchaîne un fetch puis une intégration immédiate (fusion ou rebasage) dans votre branche courante. git push, à l’inverse, envoie vos commits locaux vers le distant.

Une branche locale peut « suivre » une branche distante : c’est la branche de suivi, qui permet à Git de savoir, sans argument, d’où tirer et où pousser. On l’établit avec git push -u origin ma-branche. Comprendre que le distant n’est qu’une autre copie du même graphe de commits — ni plus, ni moins — dissipe la plupart des confusions sur la synchronisation. Vous travaillez localement, en pleine autonomie, puis vous réconciliez votre graphe avec celui du distant au moment choisi.

Choisir un modèle de branches pour une équipe

Au-delà des commandes, les équipes adoptent une convention sur la manière d’organiser leurs branches. Trois grands modèles dominent. Le plus simple, souvent appelé GitHub flow, repose sur une seule branche durable, main, toujours déployable : chaque fonctionnalité naît sur une branche courte, passe par une pull request, puis fusionne et se déploie. Léger et rapide, il convient à la majorité des projets web et à la livraison continue.

Le modèle Gitflow, plus structuré, distingue des branches de longue durée (main pour la production, develop pour l’intégration) et des branches dédiées aux versions et aux correctifs urgents. Il apporte de la rigueur aux produits à versions planifiées, au prix d’une plus grande lourdeur. À l’opposé, l’approche trunk-based mise sur des intégrations très fréquentes directement sur une branche principale unique, en s’appuyant sur des indicateurs de fonctionnalité pour masquer le code inachevé ; elle réduit les conflits mais exige une discipline et des tests automatisés solides. Le bon choix dépend de la taille de l’équipe, de la cadence de livraison et de la maturité des tests — il n’existe pas de modèle universellement supérieur.

Étiquettes, versions et automatisation

Git ne sert pas qu’à enregistrer des commits : il structure aussi la mise en production. Les étiquettes (tags) marquent des points précis de l’historique, typiquement des versions publiées. On distingue les étiquettes légères, simples signets, des étiquettes annotées, qui portent un auteur, une date et un message — ces dernières sont recommandées pour les versions officielles. Beaucoup d’équipes suivent la gestion sémantique de version (SemVer), au format MAJEUR.MINEUR.CORRECTIF, pour communiquer la portée de chaque livraison.

Autour de Git gravite enfin tout un écosystème d’automatisation. Les hooks sont des scripts déclenchés à des moments clés — par exemple un contrôle de style avant chaque commit. Les plateformes d’hébergement ajoutent l’intégration continue : à chaque push ou pull request, des serveurs compilent le projet, lancent les tests et signalent les régressions avant toute fusion. Vous n’avez pas besoin de maîtriser ces outils pour débuter, mais savoir qu’ils existent éclaire la place de Git au cœur du cycle de développement moderne : il n’est pas un simple outil de sauvegarde, mais la colonne vertébrale autour de laquelle s’organise toute la livraison logicielle.

Les commandes du quotidien : la règle des 90 %

Git compte des dizaines de commandes, mais une poignée couvre l’essentiel du travail réel. Au jour le jour, vous enchaînerez surtout git status pour faire le point, git add et git commit pour enregistrer, git switch pour changer de branche, git pull et git push pour synchroniser, et git log pour relire l’historique. À elles seules, ces quelques commandes représentent la grande majorité de l’usage quotidien d’un développeur expérimenté. Les apprendre jusqu’à l’automatisme libère l’esprit pour le vrai travail : concevoir et écrire du code.

Le reste — rebasage interactif, reflog, cherry-pick, stash — relève de situations particulières : nettoyer une série de commits avant de la partager, récupérer après une fausse manœuvre, jongler entre deux urgences. Inutile de tout retenir d’emblée. La bonne stratégie d’apprentissage consiste à maîtriser d’abord ce noyau quotidien jusqu’à ce qu’il devienne un réflexe, puis à ajouter les outils plus pointus au fur et à mesure que le besoin réel se présente. Chaque tutoriel proposé ci-dessous est conçu dans cet esprit : on construit une compétence à la fois, sur le projet fil rouge, jusqu’à ce que l’ensemble forme une maîtrise solide et durable. C’est en pratiquant régulièrement, sur de vrais projets, que ces gestes finissent par s’effacer au profit de ce qui compte vraiment, et que Git cesse d’être une source d’angoisse pour devenir un allié de confiance au quotidien.

Glossaire des termes clés

FAQ

Q : Faut-il connaître la ligne de commande, ou un outil graphique suffit-il ?
R : Les interfaces graphiques sont confortables, mais comprendre la ligne de commande reste indispensable : elle est universelle, présente sur tout serveur, et c’est elle qui révèle ce que Git fait réellement. Les tutoriels du parcours s’appuient sur la ligne de commande pour cette raison.

Q : Git convient-il aux projets non informatiques ?
R : Oui, pour tout fichier texte : documentation, configuration, articles, manuscrits. Git excelle sur le texte ; il est moins adapté aux fichiers binaires volumineux, pour lesquels existent des extensions dédiées.

Q : Quelle est la différence entre git pull et git fetch ?
R : git fetch récupère les nouveautés du dépôt distant sans toucher à votre travail ; git pull fait un fetch puis intègre aussitôt (par fusion ou rebasage). fetch est donc l’option prudente pour inspecter avant d’intégrer.

Q : Dois-je créer une branche pour chaque changement ?
R : C’est une excellente discipline, surtout en équipe : une branche par fonctionnalité ou correction garde le travail isolé et facilite la revue. En solo sur un petit projet, on peut travailler plus directement sur main.

Q : Que faire si j’ai commité un mot de passe par erreur ?
R : Changez immédiatement le secret compromis, puis purgez-le de l’historique (des outils dédiés existent). Un secret poussé doit être considéré comme exposé, même après suppression.

Q : GitHub est-il gratuit ?
R : Oui pour l’essentiel : dépôts publics et privés, collaboration et automatisations de base sont gratuits. Des offres payantes ajoutent des fonctionnalités avancées pour les organisations.

Q : Par où commencer concrètement ?
R : Par le premier tutoriel, « Les bases de Git ». Installez Git, créez un dépôt d’entraînement, et suivez le projet fil rouge : la pratique ancre les concepts bien mieux que la lecture seule.

Ressources

• Le livre Pro Git, gratuit et en français — la référence : git-scm.com/book/fr/v2
• Documentation officielle des commandes Git : git-scm.com/docs
• Documentation GitHub (en français) : docs.github.com/fr
• Pour une première approche en douceur : Git et GitHub pour débutants