Comprendre Git et GitHub

1. Le problème : travailler sans perdre le fil

Un projet évolue par petites décisions : corriger une page, ajouter un formulaire, réorganiser un dossier. Enregistrer des copies nommées projet-final, projet-final-2 puis projet-vraiment-final ne permet pas de retrouver facilement qui a changé une règle ni de réunir deux travaux parallèles. Un système de gestion de versions conserve les étapes et les relations entre elles.

Dans notre fil conducteur, l’équipe pédagogique de NKILItech prépare un portail de services. Une personne rédige l’accueil, une autre ajoute les demandes clients, une troisième relit les changements. Le dépôt doit raconter ces évolutions sans mélanger une fonctionnalité inachevée et une correction déjà validée.

Le contrôle de versions apporte une mémoire exploitable, mais il demande une méthode : sélectionner ce que l’on enregistre, écrire des messages utiles et vérifier avant de partager. Un historique rempli de secrets ou de fichiers générés ne devient pas utile simplement parce qu’il est stocké dans Git.

2. Git et GitHub : des responsabilités différentes

Git est un logiciel de gestion de versions distribué. Il fonctionne sur votre machine, y compris sans connexion. Un dépôt local conserve les objets et références nécessaires à son historique ; un clone ordinaire récupère généralement l’historique disponible, tandis qu’un clone superficiel peut volontairement le limiter.

GitHub est une plateforme qui héberge notamment des dépôts Git et leur ajoute des outils de collaboration : discussions sur les changements, pull requests, issues et automatisations. Un commit peut exister localement sans être envoyé sur GitHub. Créer un compte GitHub n’installe pas Git sur l’ordinateur.

Git peut communiquer avec d’autres plateformes et avec un simple dépôt sur un disque. Les notions de commit, de branche et de fusion sont donc indépendantes de l’interface de GitHub.

3. Le commit : un instantané relié à son histoire

Un commit enregistre un état du contenu suivi, avec des métadonnées comme l’auteur, un message et une ou plusieurs références parentes. Un commit ordinaire a généralement un parent ; le premier n’en a pas ; un commit de fusion peut en avoir plusieurs. Git stocke son contenu efficacement, sans recopier naïvement chaque fichier à chaque étape.

L’identifiant d’un commit dépend notamment de son contenu et de ses métadonnées. Modifier un commit par une réécriture produit donc un autre identifiant. Les abréviations affichées dans les exemples, comme A ou B, sont des repères pédagogiques : dans un dépôt réel, Git utilise des identifiants calculés.

Un commit est local tant qu’il n’a pas été partagé. Il n’enregistre pas automatiquement tout ce qui se trouve dans le dossier : les fichiers doivent être suivis et leur version doit être sélectionnée. C’est pourquoi « enregistrer dans l’éditeur » et « créer un commit » sont deux opérations distinctes.

4. Dépôt, branche, HEAD et dossier de travail

Le dossier de travail contient les fichiers que vous consultez et modifiez. Le répertoire caché .git conserve les données de Git. Il ne faut pas l’éditer manuellement pour corriger un historique.

Une branche est une référence mobile vers un commit. Créer une branche ne copie pas un second dossier complet. HEAD désigne habituellement la branche courante et, par elle, le commit sur lequel le travail repose. Plus loin, nous verrons le cas particulier d’un HEAD détaché.

Le nom main est une convention courante pour la branche principale ; Git n’accorde pas un pouvoir spécial à ce mot. Dans ce cours, nous créons explicitement main pour que tous les exercices partent de la même situation.

5. Local, distant et sauvegarde

Un dépôt distant est un autre dépôt avec lequel on échange des références et des objets. Le nom origin est un raccourci local généralement créé par clone. Ce n’est ni une commande magique ni un synonyme obligatoire de GitHub.

Les échanges sont explicites : on récupère ce qui existe ailleurs et on envoie les commits à partager. Un poste peut donc conserver des modifications, des commits locaux et une ancienne connaissance du dépôt distant. Avant de raisonner sur une branche distante, il faut savoir quand cette connaissance a été mise à jour.

Un hébergement distant aide à conserver et partager le travail publié. Il ne remplace pas toute sauvegarde : les fichiers ignorés, les changements non commités ou les ressources externes peuvent ne jamais y être envoyés. Le cours explique ce que chaque étape protège réellement.

6. Objectifs et méthode du parcours

À la fin du parcours, vous pourrez créer un dépôt propre, sélectionner un commit, développer sur une branche, résoudre un conflit, proposer une modification sur GitHub et choisir une méthode de récupération adaptée. Vous saurez aussi lire une automatisation simple et préparer une version livrable.

Les commandes de création de fichiers utilisent PowerShell 7. Les commandes Git restent les mêmes dans la plupart des terminaux. Dans Git Bash ou sur Linux, adaptez seulement les commandes du shell, comme Set-Content. Les exercices s’effectuent dans un dossier d’entraînement distinct de vos projets réels.

Les adresses contenant VOTRE_COMPTE doivent être remplacées par celles de votre propre dépôt d’exercice. Aucun dépôt réel de NKILItech n’est nécessaire : l’entreprise sert de contexte pédagogique.

Exercices corrigés