En bref
Un repository (ou "repo") est votre dossier de projet dès qu'il est suivi par un outil de contrôle de version, et le contrôle de version est le système qui enregistre chaque modification pour que vous puissiez toujours revenir en arrière. En clair, le contrôle de version est un historique d'annulation étiqueté et illimité pour tout votre projet, et le repo est le projet plus cet historique. C'est le socle sur lequel tout le reste se construit : sauvegardes, collaboration et déploiement commencent tous par un repo sous contrôle de version.
Ce que le contrôle de version vous donne
Le contrôle de version transforme un dossier plein de fichiers en quelque chose avec quoi vous pouvez expérimenter sans peur. Chaque modification importante est enregistrée comme un instantané auquel vous pouvez revenir, donc une mauvaise modification n'est jamais définitive. Il enregistre aussi qui a changé quoi et pourquoi, ce qui devient essentiel dès que plus d'une personne touche au projet.
Repo local vs repo distant
Votre repo vit sur votre ordinateur (le repo local) et a généralement une copie en ligne (le repo distant), le plus souvent sur GitHub. Vous travaillez en local et "poussez" vos modifications enregistrées vers le distant pour les sauvegarder et les partager. Les deux restent synchronisés à mesure que vous poussez et tirez des modifications.
Pourquoi cela compte pour livrer
Un repo n'est pas seulement pour la sécurité, c'est ce à quoi les plateformes d'hébergement se connectent. Quand votre projet est un repo sur GitHub, un hébergeur comme Vercel peut le surveiller et redéployer automatiquement votre site live chaque fois que vous poussez. Un repo propre sous contrôle de version est donc la voie d'accès pour livrer réellement votre travail.
Confusions fréquentes des débutants
Un repo peut sembler être un dossier spécial mystérieux, mais ce n'est vraiment que votre dossier de projet normal avec, en plus, un enregistrement caché des modifications. Vous modifiez les fichiers de la même façon. Les gens supposent aussi qu'un repo signifie automatiquement que tout est public ou sauvegardé ; ni l'un ni l'autre n'est vrai tant que vous ne poussez pas vers un distant et ne choisissez pas sa visibilité, et un tout nouveau repo business devrait être privé par défaut. Autre point à intégrer tôt : l'historique n'est utile qu'à la mesure de vos commits. Si vous committez rarement avec des messages vagues, le filet de sécurité est faible ; si vous committez souvent avec des messages clairs, vous pouvez revenir à tout instant en confiance. Cette seule habitude transforme le contrôle de version d'une corvée en une vraie superpuissance.