Tu as déjà nommé un fichier projet_final_v2_vraiment_final.js ? Alors tu as déjà ressenti le besoin de Git sans le savoir. Git, c’est l’outil qui garde la mémoire de ton code : chaque version, chaque modification, qui a changé quoi et quand. GitHub, c’est l’endroit où tu déposes ce code en ligne pour le sauvegarder, le partager et travailler à plusieurs. Les deux vont ensemble, mais ce sont deux choses distinctes, et c’est justement la première confusion qu’on va lever.
Autant le dire franchement : en 2026, ne pas savoir utiliser Git est rédhibitoire pour trouver un poste de développeur. Plus de 93 % des développeurs l’utilisent au quotidien, et selon les données de l’APEC, environ 95 % des offres d’emploi de dev en France mentionnent Git ou un outil de versionnement dans les compétences attendues. La bonne nouvelle, c’est que six commandes suffisent pour démarrer sérieusement. On va les voir une par une, avec un vrai projet.
Git et GitHub : ne pas confondre les deux#
Une image simple pour poser les choses. Git est un logiciel qui tourne sur ta machine et qui suit l’historique de tes fichiers. Il fonctionne totalement hors ligne : tu peux versionner un projet sans jamais toucher à Internet. GitHub, lui, est un service en ligne (racheté par Microsoft) qui héberge tes dépôts Git dans le cloud. C’est un peu comme la différence entre Word (le logiciel qui écrit le document) et Google Drive (l’endroit où tu le stockes et le partages).
Tu pourrais très bien utiliser Git tout seul dans ton coin. Mais dès que tu veux sauvegarder ton travail ailleurs que sur ton disque dur, collaborer, ou simplement montrer ton code à un recruteur, GitHub entre en jeu. Il existe des alternatives, GitLab et Bitbucket notamment, qui reposent sur exactement le même Git en dessous. Apprends Git une fois, tu sauras utiliser les trois.
Prérequis avant de commencer#
Installe Git depuis git-scm.com (l’installeur par défaut convient très bien sous Windows, macOS et Linux). Ouvre ensuite un terminal et vérifie que tout est en place :
git --version # doit afficher quelque chose comme "git version 2.49.0"Deuxième étape indispensable, configurer ton identité. Git l’associe à chacun de tes commits, une seule fois pour toutes tes futures utilisations :
# Ton nom et ton email apparaîtront dans l'historique de tes projets
git config --global user.name "Prénom Nom"
git config --global user.email "ton.email@exemple.fr"Crée aussi un compte gratuit sur github.com. On s’en servira dans la deuxième moitié de ce guide.
Ton premier dépôt en cinq commandes#
Passons à la pratique. Imagine que tu démarres un petit projet dans un dossier mon-site. Voici le cycle complet, du dossier vide au premier commit sauvegardé.
cd mon-site # on se place dans le dossier du projet
git init # crée un dépôt Git : un dossier caché .git apparaîtCe .git est le cerveau de l’opération. Il contient tout l’historique et tu n’as jamais à y toucher directement. À ce stade, Git surveille ton dossier mais ne suit encore aucun fichier. Créons-en un, puis regardons ce que Git en pense :
git status # affiche l'état actuel : fichiers non suivis, modifiés, etc.git status est ta commande la plus précieuse. Prends l’habitude de la taper tout le temps, elle te dit toujours où tu en es. Elle va te signaler tes fichiers en rouge, comme “non suivis”. Pour les faire entrer dans le prochain instantané, on les ajoute à la zone de préparation (le fameux staging) :
git add index.html # ajoute un fichier précis
git add . # ou ajoute tout le dossier d'un coupLe staging, c’est l’étape qui déroute les débutants, alors prenons le temps. Pense à une photo de groupe : git add place les personnes dans le cadre, git commit appuie sur le déclencheur. Tu choisis ce qui entre dans la photo avant de la prendre. Ça permet d’enregistrer seulement une partie de tes changements si tu le souhaites. Une fois tes fichiers en scène, on immortalise :
# -m écrit le message directement, sans ouvrir d'éditeur de texte
git commit -m "Ajout de la page d'accueil"Félicitations, tu viens de créer ton premier commit. C’est un point de sauvegarde daté, signé, auquel tu pourras toujours revenir. Refais le cycle add puis commit à chaque étape logique de ton travail, et tu construis peu à peu un historique propre.
Écrire de bons messages de commit#
Un détail qui sépare l’amateur du pro : le message de commit. “modif”, “truc”, “ça marche enfin” ne veulent rien dire dans six mois. En 2026, la convention la plus répandue s’appelle Conventional Commits. Elle préfixe le message par le type de changement :
git commit -m "feat: ajout du formulaire de contact"
git commit -m "fix: correction du bug d'affichage sur mobile"
git commit -m "docs: mise à jour du README"feat pour une nouvelle fonctionnalité, fix pour une correction, docs pour la documentation. Ce n’est pas obligatoire pour un projet perso, mais l’adopter tôt te donne un réflexe précieux en équipe.
Envoyer son code sur GitHub#
Ton historique est bien gardé en local, mais il ne survivrait pas à un disque dur qui lâche. On va donc le pousser sur GitHub. Crée d’abord un dépôt vide sur github.com (bouton “New repository”, donne-lui un nom, laisse le reste par défaut). GitHub t’affiche alors une adresse. Il ne reste qu’à relier ton dossier local à ce dépôt distant :
# "origin" est le surnom standard du dépôt distant
git remote add origin https://github.com/ton-pseudo/mon-site.git
# -u mémorise le lien : les prochains push se feront avec un simple "git push"
git push -u origin mainRafraîchis la page GitHub : ton code est en ligne. Voilà le sixième et dernier verbe du quotidien, push, qui envoie tes commits locaux vers le dépôt distant. Son miroir, git pull, fait l’inverse : il récupère les changements présents sur GitHub vers ta machine. Tu utiliseras pull dès que tu travailles sur plusieurs ordinateurs ou à plusieurs.
Un mot sur l’authentification, qui piège pas mal de débutants. GitHub n’accepte plus ton mot de passe de compte pour le push. La première fois, laisse GitHub CLI ou l’assistant d’identifiants gérer la connexion, ou génère un jeton d’accès personnel dans les réglages de ton compte. Une fois configuré, tu n’y penses plus.
Les branches : travailler sans tout casser#
Jusqu’ici on est resté sur une seule ligne de temps, la branche main. Mais l’intérêt de Git explose avec les branches. Une branche, c’est une copie parallèle de ton projet où tu peux expérimenter sans risquer d’abîmer la version qui fonctionne. Tu tentes une nouvelle fonctionnalité sur une branche à part, et si ça part en vrille, tu la supprimes sans laisser de trace sur main.
git switch -c nouvelle-fonctionnalite # crée une branche et bascule dessus
# ... tu codes, tu ajoutes, tu commites tranquillement ...
git switch main # tu reviens sur la branche principale
git merge nouvelle-fonctionnalite # tu fusionnes ton travail dans maingit switch -c crée et rejoint la nouvelle branche d’un seul geste (l’ancienne commande git checkout -b fait la même chose, tu la croiseras encore souvent). Une fois ton travail validé, git merge recolle les deux histoires. C’est le socle de la façon dont les équipes bossent : chacun sa branche, on fusionne au fur et à mesure.
La pull request, le rituel du travail en équipe#
Sur GitHub, la fusion passe souvent par une pull request (ou “PR”). Tu pousses ta branche, tu ouvres une pull request depuis l’interface web, et tu proposes officiellement d’intégrer tes changements dans main. Tes collègues relisent, commentent ligne par ligne, demandent des ajustements, puis quelqu’un valide la fusion. C’est là que se joue la vraie collaboration, et c’est ce que tout recruteur technique regardera sur ton profil.
Ligne de commande ou interface graphique ?#
Faut-il tout taper au clavier ? Pas nécessairement. GitHub Desktop, une application graphique gratuite et open source, te laisse faire add, commit, push, changer de branche à la souris, sans retenir une seule commande. VS Code intègre aussi Git nativement dans sa barre latérale. Pour démarrer, ces outils enlèvent une bonne dose d’angoisse.
Mon conseil, honnêtement : apprends quand même les commandes de base. L’interface graphique dépanne, mais dès qu’un problème sort du cadre prévu, c’est le terminal qui te sauve, et c’est ce qu’on attend de toi en entreprise. Note d’ailleurs que GitHub pousse de plus en plus son terminal enrichi (la nouvelle interface Copilot CLI, disponible depuis juin 2026, gère issues et pull requests directement en ligne de commande). La tendance ne va pas vers moins de terminal.
Combien de temps pour être à l’aise ?#
Compte deux à quatre semaines de pratique régulière pour que init, add, commit, push, pull, branch et merge deviennent des automatismes. Le secret n’est pas de lire dix tutoriels, mais d’utiliser Git sur un vrai projet, même minuscule. Versionne ton site perso, tes exercices de code, tes notes. Chaque commit est une répétition.
Le meilleur terrain d’entraînement, c’est ton propre apprentissage. Si tu suis notre guide complet pour apprendre le développement web, mets chacun de tes projets sous Git dès la première ligne. Et quand tu attaqueras des projets un peu costauds en JavaScript moderne ou en Python, tu seras déjà rodé aux branches et aux pull requests, ces réflexes que les équipes attendent au premier jour.
Récapitulons la boîte à outils du débutant : git init pour démarrer, git add et git commit pour sauvegarder, git push et git pull pour synchroniser avec GitHub, git switch et git merge pour les branches. Sept mots, et tu tiens déjà 90 % de ce que tu feras au quotidien. Le reste viendra tout seul, un commit après l’autre.
