En bref
Git est la machine à remonter le temps de ton code : à chaque étape de travail, tu prends une photo datée et commentée du projet — un commit — et l’historique complet reste consultable, restaurable, comparable. Fini les dossiers « version-finale-VRAIE-2 » : une seule copie du projet, toutes ses époques. Les branches ajoutent les univers parallèles : essayer une idée sans toucher à la version qui marche, puis fusionner si l’essai est concluant. GitHub, lui, est la maison en ligne de ces historiques : sauvegarde distante, partage, collaboration (la « pull request » : une proposition de modification relue avant d’être acceptée) — et la vitrine que les recruteurs consultent. Les six commandes de survie se lisent en mots : init (démarre le suivi), status (la boussole), add (prépare la photo), commit (prends-la), push (envoie en ligne), pull (récupère). Commencer seul, commettre souvent, messages clairs : le reste viendra.
S’il ne fallait apprendre qu’un seul outil de tout ce silo, ce serait lui : présent dans chaque équipe, chaque offre d’emploi, chaque projet sérieux — et précieux dès ton travail en solo. Git et GitHub expliqués aux débutants : la machine à remonter le temps, la maison sociale du code, et tes gestes de survie — le guide qui ouvre notre silo Outils du développeur, dans le grand parcours apprendre à coder.
Git : la machine à remonter le temps de ton code
Commence par le problème, que tu connais déjà : projet-final.zip, projet-final-2.zip, projet-VRAIMENT-final… — la gestion de versions par dossiers, son chaos, ses drames (« c’était laquelle, la bonne ? »). Git — créé en 2005 par Linus Torvalds, l’auteur de Linux, pour gérer le plus grand projet collaboratif du monde — remplace tout cela par une idée : le projet reste en un seul exemplaire, et un journal invisible enregistre son histoire. À chaque étape que TU juges digne, tu prends un commit : une photographie complète du projet à cet instant, datée, signée, et commentée — « ajout du formulaire de contact », « correction du bug du menu ». L’historique de ces photos est ta machine à remonter le temps : consulter n’importe quelle époque, comparer deux versions ligne à ligne, restaurer l’état d’avant la catastrophe — le filet de sécurité qui change la façon même de travailler : on ose, puisqu’on peut revenir.
Deuxième idée, les branches — les univers parallèles : la branche principale (main) porte la version qui marche ; pour essayer une refonte risquée, tu ouvres une branche — une ligne temporelle parallèle où tu expérimentes librement pendant que main reste intacte — puis, si l’essai convainc, tu fusionnes : les deux lignes se rejoignent, l’historique garde tout. En solo, la branche est ton bac à sable ; en équipe, elle est la condition même du travail à plusieurs sans se marcher dessus. Et une précision qui dissipe la confusion universelle : Git vit sur TA machine — c’est un outil local, complet sans internet ; ce qui nous amène à son célèbre compagnon.
GitHub : la maison sociale de ton code
GitHub n’est pas Git : c’est la maison en ligne des historiques Git — un service (racheté par Microsoft, gratuit pour l’essentiel) où tu publies une copie distante de tes dépôts. Trois services en découlent, par ordre d’importance pour toi. La sauvegarde : ton projet et TOUT son historique vivent hors de ta machine — le disque dur qui meurt n’emporte plus rien (c’est la vraie assurance-vie du code, comme le rappellera le guide du poste de travail). Le partage : un dépôt public se consulte, se clone, se sert — tu l’as déjà vécu sans le savoir en déployant ton site, qui est un dépôt GitHub servi par Pages. La collaboration, enfin, via le rituel central du métier : la pull request — littéralement une proposition de modification : « voici ma branche, voici ce qu’elle change, veux-tu la fusionner ? » — relue, commentée, amendée avant d’être acceptée ; c’est ainsi que se construit l’open source mondial, et ainsi que travaillent les équipes.
Un mot sur la dimension vitrine, car elle te concerne plus tôt que tu ne crois : le profil GitHub est le portfolio par défaut du développeur — les recruteurs y regardent moins la virtuosité que la régularité (le petit carré vert du jour) et la tenue des projets : des dépôts avec un README clair, des commits aux messages soignés racontent un artisan sérieux. Chaque projet du parcours — exercices, API, site — mérite son dépôt : commence aujourd’hui, l’historique parlera pour toi dans un an. (GitHub domine, mais n’est pas seul : GitLab et Bitbucket rendent les mêmes services — les concepts sont identiques, le choix est celui de ton équipe future.)
Tes gestes de survie — et le bon chemin d’apprentissage
Le cycle quotidien tient en six commandes, à lire en mots dans le terminal. git init : « démarre le suivi de ce dossier » — une fois par projet. git status : « où en suis-je ? » — LA boussole, à taper sans modération : elle liste ce qui a changé et ce qui est prêt. git add fichier (ou add . pour tout) : « prépare ces changements pour la photo » — la sélection de ce qui entrera dans le commit. git commit -m « message clair » : « prends la photo, avec cette légende ». git push : « envoie mes nouvelles photos à la maison GitHub ». git pull : « récupère ce qui est arrivé là-bas » — vital à plusieurs, bon réflexe seul (deux machines). Six gestes, et tu couvres 90 % de l’usage réel — VS Code les propose d’ailleurs en boutons dans son panneau Source Control : mêmes concepts, clics au lieu de commandes, excellent pour débuter des deux mains.
Le chemin d’apprentissage sain, pour finir. Commence seul et petit : un dépôt par projet d’apprentissage, des commits fréquents (chaque petite victoire — pas un commit-fleuve par semaine) aux messages qui racontent (« ajoute la validation du formulaire », pas « fix ») — tout un art détaillé dans bien utiliser les commits. N’aie pas peur de casser : la terreur du débutant (« j’ai tapé la mauvaise commande ») est infondée — Git est précisément la machine qui n’oublie rien : presque tout se récupère, et status te dit toujours où tu es. Garde les branches et les pull requests pour l’étape deux : le cycle add-commit-push maîtrisé en solo est la fondation ; le reste s’ajoute naturellement quand un deuxième humain (ou un deuxième toi, celui de la refonte risquée) entre en scène. L’outil des vingt prochaines années de ta vie de développeur tient dans cette page — installe, initialise, photographie : l’historique commence maintenant.
Questions fréquentes
Quelle est la différence entre Git et GitHub ?
Git est l’outil, local, installé sur ta machine : il enregistre l’historique de ton projet en commits, gère les branches, fonctionne sans internet. GitHub est un service en ligne qui héberge une copie de ces dépôts Git : sauvegarde, partage, collaboration (pull requests) — et vitrine publique de ton travail.
C’est quoi un commit ?
Une photographie complète et commentée de ton projet à un instant donné : datée, signée, accompagnée d’un message qui raconte le changement (« ajout du formulaire de contact »). L’enchaînement des commits forme l’historique — consultable, comparable, restaurable : ta machine à remonter le temps.
À quoi sert une branche dans Git ?
À travailler dans un univers parallèle : la branche principale garde la version qui marche pendant que tu expérimentes librement ailleurs — refonte, nouvelle fonctionnalité, essai risqué. Si l’essai convainc, tu fusionnes les deux lignes ; sinon, tu jettes la branche, sans que rien n’ait été cassé.
Faut-il apprendre Git en ligne de commande ou via VS Code ?
Les deux se complètent : le panneau Source Control de VS Code rend les gestes visuels et rassurants pour débuter, la ligne de commande (init, status, add, commit, push, pull) donne la compréhension et l’universalité — c’est elle que montrent les documentations et les équipes. Commence où tu es à l’aise, vise les deux.
Sources
- Git — le site officiel et le livre Pro Git en libre accès
- GitHub Docs — la documentation officielle de la plateforme
Cet article a une vocation informative et pédagogique. Les plateformes, outils et formations éventuellement cités le sont à titre d’exemple ; compare plusieurs options avant de t’engager ou de payer.