Voici le point clé
- Git agit comme un carnet de bord local sur votre machine, enregistrant chaque changement sans connexion internet.
- Les bases indispensables pour le développeur passent par la commande git add, qui marque les fichiers à surveiller.
- Le workflow débute par l’installation et git init, puis configure l’identité avant le premier envoi.
Sur un bureau d’architecte, une lampe en métal terni éclaire des croquis éparpillés, des calques superposés, des idées en cours de maturation. Entre deux tracés au crayon, un écran affiche une interface sobre: des lignes de code s’alignent, nettes, sous un terminal. Ce contraste parle d’un autre type d’organisation - pas celle du trait ou de la perspective, mais du temps. Car comme on plie un plan pour retrouver une version antérieure, le développeur versionne son travail pour ne jamais perdre une idée, une correction, un progrès. C’est là, dans cette volonté de garder trace, que Git et GitHub entrent en scène, non comme des outils magiques, mais comme des compagnons discrets du quotidien numérique.
Comprendre Git et GitHub: la comparaison des rôles
Git, l'outil de gestion en local
Imaginez un carnet de notes qui enregistre chaque modification, mot par mot, sans que vous ayez à tout copier manuellement. C’est exactement ce que fait Git sur votre machine. Ce logiciel fonctionne en arrière-plan, directement dans votre dossier de projet. Il n’a pas besoin de connexion internet pour fonctionner. Dès que vous modifiez un fichier, Git le remarque, et vous pouvez choisir de « valider » ce changement avec un message explicite. Chaque validation devient un point dans l’historique de versionnage, que vous pouvez consulter ou revenir dessus plus tard. C’est un filet de sécurité permanent.
GitHub, la plateforme de collaboration en ligne
Si Git est le cahier personnel, GitHub est la bibliothèque publique. C’est un service web qui héberge des projets versionnés avec Git. Vous pouvez y déposer votre code pour le partager, le sauvegarder en lieu sûr, ou travailler à plusieurs dessus. Lorsque plusieurs développeurs interviennent sur un même projet, GitHub permet de suivre les modifications de chacun, de proposer des correctifs, de discuter de morceaux de code - bref, de transformer un travail solitaire en travail en équipe. C’est aussi là que le collaboration Open Source prend tout son sens: n’importe qui peut consulter, utiliser ou améliorer un projet.
| Caractéristique | Git | GitHub |
|---|---|---|
| Type | Logiciel local | Service en ligne |
| Installation requise | Oui, sur l’ordinateur | Non (accès par navigateur) |
| Stockage | Sur le disque dur local | Dans le cloud |
| Interface | Ligne de commande ou interface graphique | Interface web |
| Coût | Gratuit (open source) | Gratuit pour les projets publics |
Les bases indispensables pour le développeur
Le cycle de vie d'un commit
Quand vous modifiez un fichier dans un projet suivi par Git, il ne se passe rien d’extraordinaire… au début. Git voit que quelque chose a changé, mais n’agit pas seul. La première étape, c’est l’« ajout » - en commande, on dit git add. Cela signifie: « Je veux que tu surveilles ces changements. » Ensuite vient la validation, le « commit » (git commit), accompagné d’un message. Ce commit devient alors un point de sauvegarde dans l’historique. C’est un peu comme poser un jalôn dans un sentier: si vous vous perdez, vous pouvez revenir à ce point. Ce cycle - modifier, ajouter, valider - est la colonne vertébrale de Git.
La puissance des branches de travail
Vous avez une idée de nouvelle fonctionnalité, mais vous ne voulez pas risquer de casser le projet principal? Pas de panique. Git permet de créer une « branche », une sorte de voie parallèle où expérimenter en toute sécurité. Vous codez, vous testez, tout cela en dehors du chemin principal appelé souvent main ou master. Une fois que tout fonctionne, vous « fusionnez » votre branche avec la principale. Ce système permet aux équipes de travailler en parallèle sans se marcher dessus. C’est une des clés de la sécurisation des sources dans les projets complexes.
Workflow simple: de l'installation au partage
Initialiser son premier projet
Pour commencer avec Git, il faut d’abord l’installer sur son ordinateur - cela ne prend que quelques minutes. Ensuite, dans un dossier de projet, vous lancez la commande git init. Cela crée un dépôt local. Vous configurez ensuite votre identité avec git config --global user.name et git config --global user.email, pour que chaque modification soit liée à vous. Si vous récupérez un projet existant, vous utiliserez plutôt git clone, qui copie tout le code et son historique.
Pousser ses modifications vers le cloud
Une fois que vous avez fait quelques commits localement, vous pouvez synchroniser votre travail avec un dépôt distant, par exemple sur GitHub. Cela se fait avec git push. Mais attention: avant de pousser, il est sage de vérifier que personne n’a modifié le projet entre-temps - d’où l’utilité de git pull pour récupérer les dernières mises à jour. Une bonne pratique? Rédiger des messages de commit clairs et précis, comme « Correction bug formulaire de contact » plutôt que « fix ». Cela facilite la lecture de l’historique pour vous… et pour les autres.
git init- Crée un nouveau dépôt Git videgit add- Ajoute des fichiers à la prochaine validationgit commit- Enregistre les changements avec un messagegit status- Affiche l’état des fichiers (modifiés, prêts, etc.)git push- Envoie les commits locaux vers un dépôt distant
Les questions les plus habituelles
Que faire si je supprime par erreur un fichier important dans mon dossier local?
Git garde trace de tout tant que le commit n’a pas été supprimé. Vous pouvez restaurer le fichier avec la commande git checkout HEAD~1 -- nom-du-fichier ou en revenant à un commit antérieur. L’important est d’agir rapidement, avant de perdre l’historique local.
Quelle licence choisir sur GitHub pour protéger mon code personnel?
Les licences déterminent comment les autres peuvent utiliser votre code. MIT est simple et permissive: tout le monde peut l’utiliser, même en commercial, à condition de vous citer. GPL est plus restrictive et oblige à partager les modifications. Pour un projet personnel, MIT suffit souvent.
À quelle fréquence devrais-je envoyer mes commits sur le serveur distant?
Idéalement, plusieurs fois par jour. Cela dépend du projet, mais pousser régulièrement évite les conflits et assure une sauvegarde continue. Un bon rythme: après chaque fonctionnalité terminée ou chaque correction majeure.