Un jour, un stagiaire m'a envoyé un dossier zippé nommé site_final_VRAI_final_cettefois.zip. Trois semaines plus tard, on cherchait encore quelle version contenait le bon formulaire de contact. On a perdu une demi-journée à comparer des fichiers à la main. Ce jour-là, j'ai compris que le problème n'était pas le stagiaire. C'était notre méthode de travail.
Si vous gérez des projets — du code, des textes, des scripts, des configs — sans outil de versionnage, vous accumulez de la dette silencieuse. Et cette dette se paie toujours au pire moment. Voilà pourquoi utiliser Git et GitHub n'est pas une lubie de développeur, mais une décision de gestion de projet à part entière.
Points clés à retenir
- Git est l'outil qui enregistre l'historique de votre projet ; GitHub est la plateforme où cet historique se partage et se collabore. Deux choses différentes, souvent confondues.
- Le versionnage remplace les copies de dossiers du type v2_final_bis par un historique clair et consultable.
- Les branches permettent de tester une idée sans casser ce qui fonctionne déjà.
- La revue de code via pull request attrape des erreurs avant qu'elles n'atteignent la production.
- Git n'est pas adapté à tout : gros fichiers binaires, données sensibles et équipes non techniques demandent d'autres réflexes.
- Sur un projet solo, l'intérêt principal n'est pas la collaboration mais la possibilité de revenir en arrière sans panique.
Pourquoi utiliser Git et GitHub quand on gère des projets
La première fois qu'on m'a montré Git, j'ai trouvé ça inutilement compliqué. Je gérais un petit site, trois fichiers, une base de données. Pourquoi installer un logiciel en ligne de commande pour ça ? J'ai continué à travailler à l'ancienne pendant des mois. Puis le projet a grossi, on est passés à deux, puis à quatre. Et là, ça a explosé.
Git et GitHub, c'est la même chose ?
Non, et cette confusion coûte cher. Git est un logiciel qui tourne sur votre machine. Il enregistre chaque modification de votre projet sous forme de commits — des instantanés horodatés. Il fonctionne sans internet, sans compte, sans plateforme. GitHub, c'est un service en ligne qui héberge des dépôts Git, avec des fonctionnalités de collaboration par-dessus : revue de code, suivi des tâches, gestion des droits.
Vous pouvez très bien utiliser Git sans jamais toucher à GitHub. Vous pouvez aussi utiliser GitHub avec un autre outil de versionnage, mais c'est rare.
Le raccourci que je donne à mes clients : Git est le moteur, GitHub est le garage où tout le monde se retrouve pour travailler dessus et discuter des réparations.
Le vrai problème que Git résout (et que vous avez déjà)
Ouvrez le dossier de votre dernier projet. Combien de fichiers portent un nom du genre rapport_v3_corrigé_martin ? Si la réponse est « plus qu'un », vous gérez déjà du versionnage — manuellement, mal, et sans historique fiable.
Git remplace ça par une seule règle : chaque modification importante devient un commit avec un message. Vous pouvez décrire ce qui a changé, retrouver la version d'il y a six mois, et comparer deux états côte à côte. Sur un projet de rédaction technique que j'ai suivi, on est passés de 40 copies de fichiers à un historique linéaire de 220 commits. Le temps passé à chercher « la bonne version » est tombé à zéro, tout simplement parce qu'il n'y avait plus qu'une seule version vivante.
Ce que ça change concrètement dans votre gestion de projet
On parle souvent de Git en termes abstraits : « traçabilité », « collaboration », « sécurité ». Franchement, ça ne dit rien à personne. Regardons plutôt ce qui se passe dans la vraie vie.
Revenir en arrière sans paniquer
C'est le bénéfice numéro un, et celui qu'on sous-estime le plus. Une modification casse quelque chose en production ? Avec Git, vous identifiez le commit fautif et vous revenez à l'état précédent en quelques secondes. Sans Git, vous passez une heure à défaire à la main ce que vous venez de faire, en priant pour ne rien oublier.
J'ai cassé le site d'un client un vendredi après-midi en modifiant une règle de redirection. Trois minutes plus tard, c'était réparé. Si j'avais travaillé sans historique, j'aurais probablement cherché jusqu'au soir.
Travailler à plusieurs sans se marcher dessus
Les branches sont la fonctionnalité qui change tout en équipe. Chacun travaille sur sa copie du projet, dans sa branche, sans toucher à la version principale. Quand le travail est prêt, on le fusionne. Si deux personnes ont modifié le même endroit, Git signale un conflit — et vous le résolvez une fois, proprement, au lieu de découvrir le problème trois semaines plus tard.
Sur une équipe de quatre que j'ai accompagnée, les conflits ont chuté simplement parce qu'ils étaient détectés au moment de la fusion et non à la mise en ligne. Le vrai gain n'est pas le nombre de conflits, c'est le moment où ils apparaissent.
La revue de code : attraper les erreurs avant la production
Sur GitHub, une pull request (ou merge request) est une proposition de fusion. Avant d'accepter, quelqu'un relit les modifications ligne par ligne. C'est un filet de sécurité redoutable : une faute de frappe dans une condition, une clé d'API oubliée en dur, une requête qui va plomber la base de données.
Est-ce que tout le monde fait des revues sérieuses ? Non. J'ai vu des équipes approuver des pull requests en dix secondes. Mais le mécanisme existe, il est visible, et il responsabilise. Rien que le fait de savoir que quelqu'un va lire votre code change votre façon de l'écrire.
Git et GitHub face aux alternatives
Git n'est pas seul. Il existe GitLab, Bitbucket, et des outils plus anciens comme SVN. Faut-il choisir GitHub par défaut ? Pas forcément, et ça mérite un tableau plutôt qu'un discours.
| Solution | Points forts | Limites |
|---|---|---|
| Git + GitHub | Écosystème immense, intégrations nombreuses, dépôts publics gratuits | Interface parfois chargée, fonctionnalités avancées payantes |
| Git + GitLab | Installation sur serveur interne, chaîne d'intégration incluse | Interface moins familière pour les débutants |
| Git + Bitbucket | Bien intégré aux outils Atlassian d'une entreprise | Moins de projets publics, communauté plus restreinte |
| SVN | Modèle simple, adapté aux très gros fichiers binaires | Pas de travail hors ligne, branches lourdes à gérer |
Mon avis, et je le défends : pour la majorité des projets, Git plus GitHub reste le choix le plus confortable, ne serait-ce que parce que tout le monde connaît. Mais si votre organisation impose un serveur interne pour des raisons légales, GitLab fait très bien le travail.
Quand Git et GitHub ne sont pas la bonne réponse
Il faut le dire, parce qu'on lit partout que Git résout tout. Ce n'est pas vrai.
Les gros fichiers binaires
Git garde l'historique complet de chaque fichier. Sur un projet de montage vidéo avec des rushes de plusieurs gigaoctets, l'outil devient vite ingérable. Il existe des extensions dédiées, mais elles ajoutent de la complexité. Si votre travail tourne autour de gros médias, réfléchissez avant de foncer.
Les données sensibles
Un dépôt Git conserve tout, y compris ce que vous regrettez d'avoir mis. Si vous poussez par erreur une clé d'API ou un fichier de mots de passe, elle reste dans l'historique même après suppression. J'ai vu une clé compromise rester exposée deux semaines parce que personne n'avait pensé à changer la clé elle-même. Le réflexe : ne jamais mettre de secret dans un dépôt, point.
Les équipes non techniques
Pour une équipe marketing qui gère des documents partagés, Git est probablement un marteau-pilon. Google Docs avec son historique de versions fait le travail pour beaucoup moins d'effort. Git brille quand on a besoin de branches, de revues et de déploiements automatisés. Sinon, il ajoute de la friction.
Par où commencer sans se noyer
N'essayez pas d'apprendre tout Git d'un coup. J'ai fait cette erreur : trois jours à lire la documentation, aucune ligne de code écrite. Voici un ordre plus raisonnable.
- Apprenez commit, push et pull. C'est 80 % de votre usage quotidien.
- Créez un dépôt privé sur GitHub pour un projet perso, même minuscule.
- Prenez l'habitude d'un message de commit clair : ce que vous avez changé, pas comment.
- Passez aux branches seulement quand vous en aurez vraiment besoin.
- Ajoutez la revue de code et les pull requests en dernier.
Sur mon premier dépôt, mes messages de commit disaient tous « update ». Aujourd'hui, je relis mes anciens projets et je ne comprends rien à ce que j'ai fait. C'est exactement le contraire de l'objectif.
Ce qu'il faut vraiment retenir
Git ne rend pas un projet meilleur par magie. Il rend les erreurs réversibles, les décisions traçables et le travail à plusieurs possible sans chaos. C'est un outil de gestion autant qu'un outil technique, et c'est pour ça qu'il dépasse largement le cercle des développeurs.
La vraie question n'est pas « pourquoi utiliser Git et GitHub », mais plutôt : combien de temps allez-vous encore passer à chercher la bonne version d'un fichier ? Si vous avez souri en lisant la première phrase de cet article, vous avez déjà votre réponse.
