Github 🐙 Guide Complet : Utiliser Git & GitHub via SSH Ce guide explique comment relier une machine Linux (comme un poste de dĂ©veloppeur, un serveur ou un Bastion) Ă  un dĂ©pĂŽt GitHub en utilisant une clĂ© SSH, et dĂ©taille les commandes quotidiennes pour travailler sur son code (Clone, Pull, Commit, Push). 1. 🔑 Étape prĂ©liminaire : DĂ©clarer sa machine sur GitHub Pour pouvoir interagir avec GitHub sans jamais avoir Ă  taper de mot de passe, GitHub doit connaĂźtre la clĂ© publique de votre machine. A. RĂ©cupĂ©rer la clĂ© publique locale Sur le terminal de la machine qui va cloner le code (ex: votre Bastion), affichez votre clĂ© publique : cat ~/.ssh/id_ed25519.pub Note : Si la commande vous dit que le fichier n'existe pas, gĂ©nĂ©rez d'abord une clĂ© avec ssh-keygen -t ed25519 . SĂ©lectionnez et copiez l'intĂ©gralitĂ© du rĂ©sultat (qui commence par ssh-ed25519... ). B. Ajouter la clĂ© sur GitHub Connectez-vous Ă  votre compte sur GitHub. Cliquez sur votre photo de profil en haut Ă  droite, puis sur Settings . Dans la barre latĂ©rale gauche, cliquez sur SSH and GPG keys . Cliquez sur le bouton vert New SSH key . Title : Donnez un nom clair pour identifier la machine (ex: Bastion Proxmox ou PC Portable Perso ). Key type : Laissez sur Authentication Key . Key : Collez votre clĂ© publique. Cliquez sur Add SSH key . 2. đŸ“„ Cloner le dĂ©pĂŽt (Le rapatriement initial) Maintenant que GitHub connaĂźt votre machine, vous pouvez tĂ©lĂ©charger votre code. On appelle ça un Clone . C'est une action que l'on ne fait qu'une seule fois par machine. # Remplacer par l'URL SSH de votre propre dĂ©pĂŽt git clone git@github.com:VotrePseudo/nom-du-repo.git 💡 Astuce : Placez-vous toujours dans le bon dossier (ex: cd ~ ou cd /opt ) avant de lancer cette commande, car Git crĂ©era un sous-dossier portant le nom du dĂ©pĂŽt Ă  cet endroit. 3. ⚙ Configuration de l'identitĂ© Git (À faire une fois) Avant de pouvoir enregistrer des modifications (commit), Git a besoin de savoir "qui" vous ĂȘtes pour signer votre travail. Placez-vous dans votre nouveau dossier et lancez ces deux commandes : cd nom-du-repo git config --global user.name "Votre Nom ou Pseudo" git config --global user.email "votre-email@github.com" 4. 🔄 Le Workflow Quotidien (Le cycle de vie du code) A. TĂ©lĂ©charger les derniĂšres mises Ă  jour (PULL) Avant de commencer Ă  travailler, il faut toujours s'assurer d'avoir la derniĂšre version du code (au cas oĂč vous l'auriez modifiĂ© depuis un autre PC ou via l'interface web). git pull B. VĂ©rifier l'Ă©tat de ses fichiers (STATUS) Pour voir quels fichiers vous avez modifiĂ©s, créés ou supprimĂ©s sur votre machine : git status C. Ajouter ses modifications (ADD) Pour dire Ă  Git de prendre en compte vos modifications en vue de la prochaine sauvegarde (on place les fichiers dans le "panier") : # Pour ajouter un fichier prĂ©cis : git add chemin/vers/le/fichier.yml # Pour TOUT ajouter d'un coup (le plus courant) : git add . D. Valider la sauvegarde (COMMIT) C'est l'acte de sauvegarder le contenu de votre "panier" dans l'historique local, avec un message expliquant ce que vous avez fait. git commit -m "Ajout du serveur DHCP dans l'inventaire Ansible" E. Envoyer sur GitHub (PUSH) Vos modifications sont sauvegardĂ©es sur votre PC, mais pas encore sur le serveur GitHub ! Il faut les "pousser" vers le nuage. git push 🎉 RĂ©sumĂ© de la boucle de travail standard : Je modifie mes fichiers ➔ git add . ➔ git commit -m "Message" ➔ git push . Configuration Git sous Windows avec GitHub / GitLab, token et Visual Studio Code Cette procĂ©dure dĂ©crit la configuration d'un poste Windows pour travailler avec des dĂ©pĂŽts Git hĂ©bergĂ©s sur  GitHub ou GitLab , depuis Git Bash et Visual Studio Code. La mĂ©thode prĂ©sentĂ©e utilise HTTPS et un Personal Access Token (PAT) ou un token Ă©quivalent, associĂ© Ă  Git Credential Manager (GCM) . 1. Principe gĂ©nĂ©ral GitHub et GitLab peuvent utiliser une authentification diffĂ©rente de celle utilisĂ©e pour accĂ©der Ă  leur interface Web. Lorsque l'authentification par mot de passe classique n'est pas disponible, notamment avec le SSO ou la double authentification, un token est utilisĂ© pour les opĂ©rations Git en HTTPS. Visual Studio Code / Git Bash | | HTTPS v Git Credential Manager | | Token v GitHub ou GitLab Git Credential Manager permet de gĂ©rer les informations d'authentification sans avoir Ă  stocker manuellement le token dans un fichier texte ou dans l'URL du dĂ©pĂŽt. 2. PrĂ©requis Windows. Un compte GitHub ou GitLab. Les droits nĂ©cessaires sur le dĂ©pĂŽt concernĂ©. Git installĂ©. Git Credential Manager installĂ©. Visual Studio Code installĂ©. 3. Choisir GitHub ou GitLab La procĂ©dure Git est quasiment identique pour GitHub et GitLab. La principale diffĂ©rence concerne la crĂ©ation et les permissions du token. Plateforme Authentification Git HTTPS Token GitHub HTTPS Personal Access Token GitLab HTTPS Personal Access Token 4. CrĂ©er le token Le token doit ĂȘtre créé depuis les paramĂštres du compte de la plateforme utilisĂ©e. 4.1 GitHub Dans GitHub, accĂ©der aux paramĂštres du compte puis Ă  la gestion des Personal Access Tokens . GitHub propose notamment les tokens Fine-grained , qui permettent de limiter les permissions Ă  certains dĂ©pĂŽts et Ă  certaines opĂ©rations. Pour un usage Git classique, accorder uniquement les permissions nĂ©cessaires Ă  la lecture et Ă  l'Ă©criture des dĂ©pĂŽts concernĂ©s. 4.2 GitLab Dans GitLab, accĂ©der au profil puis Ă  : Edit profile | +--> Access | +--> Personal access tokens Pour un usage Git HTTPS classique, le scope write_repository permet les opĂ©rations de lecture et d'Ă©criture nĂ©cessaires au dĂ©pĂŽt. 5. Bonnes pratiques pour le token Donner au token uniquement les permissions nĂ©cessaires. Pour un usage Git classique : clone fetch pull push il faut disposer de droits permettant au minimum la lecture du dĂ©pĂŽt et, pour le push, de droits d'Ă©criture. Bonne pratique : ne pas donner une permission globale de type API lorsque les seules opĂ©rations nĂ©cessaires sont les opĂ©rations Git classiques. Expiration Lorsque la plateforme le permet, dĂ©finir une date d'expiration adaptĂ©e Ă  la politique de sĂ©curitĂ© de l'organisation. Stockage du token ATTENTION : un token est une donnĂ©e secrĂšte. Ne jamais le communiquer par email, messagerie instantanĂ©e, ticket ou dĂ©pĂŽt Git. Le token complet peut n'ĂȘtre affichĂ© qu'au moment de sa crĂ©ation. Le conserver temporairement dans un gestionnaire de mots de passe ou de secrets si nĂ©cessaire. 6. Installer et vĂ©rifier Git Ouvrir Git Bash ou le terminal intĂ©grĂ© de Visual Studio Code. VĂ©rifier la version de Git : git --version Exemple : git version 2.49.0.windows.1 Une version rĂ©cente de Git pour Windows inclut gĂ©nĂ©ralement Git Credential Manager. 7. VĂ©rifier Git Credential Manager VĂ©rifier sa prĂ©sence : git credential-manager --version Exemple : 2.6.1 Effectuer ensuite un diagnostic : git credential-manager diagnose Le rĂ©sultat doit notamment indiquer que le stockage des credentials fonctionne. 8. VĂ©rifier le credential helper Git ExĂ©cuter : git config --show-origin --get-all credential.helper Un rĂ©sultat contenant : manager indique que Git utilise Git Credential Manager. Exemple : file:C:/Program Files/Git/etc/gitconfig manager 9. Ne pas crĂ©er manuellement .gitcredentials Lorsque Git Credential Manager est installĂ© et configurĂ©, il n'est pas nĂ©cessaire de crĂ©er manuellement un fichier .gitcredentials . Il est dĂ©conseillĂ© d'utiliser une configuration qui stocke le token directement dans un fichier texte en clair. À Ă©viter : ~/.git-credentials contenant directement un token. Il est Ă©galement dĂ©conseillĂ© de mettre le token directement dans l'URL du dĂ©pĂŽt. À Ă©viter : https://username:token@serveur.example/repository.git Important : ne jamais mettre un Personal Access Token directement dans une commande git clone , une URL Git, un script ou un fichier de configuration versionnĂ©. 10. Configurer l'identitĂ© Git Le nom et l'adresse email Git sont utilisĂ©s pour identifier l'auteur des commits. Ils sont indĂ©pendants du token utilisĂ© pour s'authentifier. 10.1 VĂ©rifier la configuration git config --global user.name git config --global user.email 10.2 Configurer le nom git config --global user.name "PrĂ©nom Nom" 10.3 Configurer l'adresse email git config --global user.email "prenom.nom@example.com" Utiliser une adresse email reconnue par la plateforme Git utilisĂ©e lorsque cela est nĂ©cessaire pour associer correctement les commits au compte. 11. RĂ©cupĂ©rer l'URL HTTPS du dĂ©pĂŽt Ouvrir le dĂ©pĂŽt dans GitHub ou GitLab. Rechercher l'option permettant de cloner le dĂ©pĂŽt puis sĂ©lectionner HTTPS . Une URL peut ressembler Ă  : https://github.com/organisation/projet.git ou : https://gitlab.example.com/groupe/projet.git L'URL exacte dĂ©pend de la plateforme et du serveur utilisĂ©. 12. CrĂ©er un rĂ©pertoire local CrĂ©er un rĂ©pertoire destinĂ© aux dĂ©pĂŽts Git. Exemple : mkdir ~/Github Se positionner dans le rĂ©pertoire : cd ~/Github Le nom du rĂ©pertoire est libre. Il peut par exemple ĂȘtre : ~/Github ~/Git ~/Repositories ~/Dev 13. Cloner un dĂ©pĂŽt Utiliser l'URL HTTPS fournie par GitHub ou GitLab. Exemple GitHub : git clone https://github.com/organisation/projet.git Exemple GitLab : git clone https://gitlab.example.com/groupe/projet.git Git peut alors demander les informations d'authentification. 14. Authentification avec le token Lors de la premiĂšre connexion, Git Credential Manager peut ouvrir une fenĂȘtre d'authentification. Si Git demande directement les credentials dans le terminal : Champ Valeur Username Nom d'utilisateur du compte Password Personal Access Token Attention : dans le champ Password, saisir le token et non le mot de passe du compte. 15. Fonctionnement de Git Credential Manager Lors du premier accĂšs : git pull / git clone | v Git Credential Manager | v Authentification | v Stockage sĂ©curisĂ© des credentials Lors des accĂšs suivants : git pull / git push | v Git Credential Manager | v Credential dĂ©jĂ  enregistrĂ© | v Serveur Git Le token n'a donc normalement pas besoin d'ĂȘtre saisi Ă  chaque opĂ©ration. 16. VĂ©rifier le dĂ©pĂŽt clonĂ© Entrer dans le rĂ©pertoire du dĂ©pĂŽt : cd projet VĂ©rifier l'URL du dĂ©pĂŽt distant : git remote -v Exemple : origin https://github.com/organisation/projet.git (fetch) origin https://github.com/organisation/projet.git (push) Ou avec GitLab : origin https://gitlab.example.com/groupe/projet.git (fetch) origin https://gitlab.example.com/groupe/projet.git (push) 17. Tester le pull git pull Si le dĂ©pĂŽt est dĂ©jĂ  Ă  jour : Already up to date. Sinon, Git rĂ©cupĂšre les modifications disponibles sur le serveur. 18. Tester le statut du dĂ©pĂŽt git status Exemple de rĂ©sultat : On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean 19. Modifier un fichier Modifier normalement les fichiers du projet avec Visual Studio Code. AprĂšs modification, vĂ©rifier l'Ă©tat : git status Les fichiers modifiĂ©s apparaissent alors dans la liste des changements. 20. Ajouter les modifications Ajouter un fichier prĂ©cis : git add fichier.txt Ajouter toutes les modifications : git add . VĂ©rifier ensuite : git status 21. CrĂ©er un commit git commit -m "Description de la modification" Utiliser un message de commit suffisamment explicite pour comprendre la modification effectuĂ©e. 22. Envoyer les modifications git push Git envoie alors les commits locaux vers le dĂ©pĂŽt distant. 23. Workflow Git quotidien # RĂ©cupĂ©rer les derniĂšres modifications git pull # VĂ©rifier l'Ă©tat du dĂ©pĂŽt git status # Modifier les fichiers # Ajouter les modifications git add . # CrĂ©er le commit git commit -m "Description de la modification" # Envoyer les modifications git push 24. Utiliser Git avec Visual Studio Code Visual Studio Code utilise directement l'installation Git prĂ©sente sur le poste. Il n'est donc pas nĂ©cessaire d'installer un deuxiĂšme Git uniquement pour VS Code. 24.1 Ouvrir un dĂ©pĂŽt Depuis Git Bash : cd ~/Github/projet code . Le dĂ©pĂŽt est alors ouvert dans Visual Studio Code. 24.2 Source Control Dans Visual Studio Code, sĂ©lectionner l'icĂŽne Source Control dans la barre latĂ©rale gauche. Les fichiers modifiĂ©s apparaissent dans la section Changes . 24.3 Stage / git add Cliquer sur le bouton + Ă  cĂŽtĂ© d'un fichier permet de le placer dans la zone de staging. Cela correspond Ă  : git add fichier 24.4 Commit Entrer le message de commit puis sĂ©lectionner Commit . Cela correspond Ă  : git commit -m "Description de la modification" 24.5 Pull Utiliser l'action Pull disponible dans les commandes Git de Visual Studio Code. Équivalent terminal : git pull 24.6 Push Utiliser Push ou Sync Changes , selon la version de Visual Studio Code. Équivalent terminal : git push 25. Correspondance VS Code / Git Action dans VS Code Commande Git Afficher les changements git status Stage d'un fichier git add fichier Stage de tous les fichiers git add . Commit git commit -m "..." Pull git pull Push git push 26. Plusieurs dĂ©pĂŽts Il est possible d'utiliser le mĂȘme compte et le mĂȘme mĂ©canisme d'authentification pour plusieurs dĂ©pĂŽts accessibles avec ce compte, dans la limite des permissions accordĂ©es au token. Exemple : Github/ ├── projet-a/ ├── projet-b/ ├── projet-c/ └── projet-d/ Chaque dĂ©pĂŽt possĂšde son propre rĂ©pertoire .git . Le rĂ©pertoire .git est créé automatiquement par Git lors d'un git clone . 27. Fichiers et Ă©lĂ©ments Ă  ne pas crĂ©er manuellement ÉlĂ©ment Action .git Ne pas crĂ©er manuellement. Git le crĂ©e automatiquement. .gitcredentials Ne pas crĂ©er manuellement lorsque Git Credential Manager est utilisĂ©. Token dans une URL À Ă©viter. Token dans un script À Ă©viter. Token dans un dĂ©pĂŽt Git Interdit. 28. VĂ©rification complĂšte de la configuration Les commandes suivantes permettent de vĂ©rifier la configuration du poste : # Version Git git --version # Version Git Credential Manager git credential-manager --version # Diagnostic Git Credential Manager git credential-manager diagnose # Credential helper utilisĂ© git config --show-origin --get-all credential.helper # IdentitĂ© Git git config --global user.name git config --global user.email # Remote du dĂ©pĂŽt git remote -v # Etat du dĂ©pĂŽt git status 29. DĂ©pannage 29.1 Git demande le token Ă  chaque opĂ©ration VĂ©rifier le credential helper : git config --show-origin --get-all credential.helper VĂ©rifier Ă©galement Git Credential Manager : git credential-manager diagnose Si le stockage des credentials est fonctionnel mais que l'authentification est systĂ©matiquement redemandĂ©e, vĂ©rifier l'URL du remote et les credentials enregistrĂ©s pour le serveur concernĂ©. 29.2 Le token est refusĂ© VĂ©rifier : que le token n'est pas expirĂ© ; que le token n'a pas Ă©tĂ© rĂ©voquĂ© ; que le token possĂšde les permissions nĂ©cessaires ; que le compte possĂšde les droits nĂ©cessaires sur le dĂ©pĂŽt ; que le bon serveur Git est utilisĂ© ; que le token est utilisĂ© comme mot de passe. 29.3 Le pull fonctionne mais le push Ă©choue Ce cas indique gĂ©nĂ©ralement un problĂšme de droits d'Ă©criture. VĂ©rifier les permissions du token et les droits du compte sur le dĂ©pĂŽt. 29.4 VĂ©rifier l'URL du dĂ©pĂŽt git remote -v VĂ©rifier que l'URL correspond bien au dĂ©pĂŽt attendu et utilise HTTPS. 30. SĂ©curitĂ© Ne jamais communiquer un Personal Access Token. Ne jamais mettre un token dans une URL Git. Ne jamais mettre un token dans un script en clair. Ne jamais committer un token dans un dĂ©pĂŽt. Utiliser une date d'expiration lorsque cela est possible. Utiliser les permissions minimales nĂ©cessaires. RĂ©voquer immĂ©diatement un token suspect ou compromis. Utiliser Git Credential Manager pour la gestion des credentials. 31. Extension GitHub / GitLab pour Visual Studio Code Les opĂ©rations Git classiques ne nĂ©cessitent pas obligatoirement l'extension spĂ©cifique Ă  la plateforme. Pour : clone pull add commit push Git + Git Credential Manager + Visual Studio Code suffisent. Les extensions GitHub ou GitLab peuvent ĂȘtre ajoutĂ©es pour bĂ©nĂ©ficier de fonctionnalitĂ©s supplĂ©mentaires propres Ă  la plateforme, comme les Pull Requests, Merge Requests, Issues ou Pipelines. Les permissions nĂ©cessaires au token peuvent alors ĂȘtre diffĂ©rentes de celles nĂ©cessaires uniquement pour les opĂ©rations Git. 32. Architecture recommandĂ©e GitHub / GitLab ^ | HTTPS | | Git Credential Manager ^ | | Git / Visual Studio Code ^ | | Repository local 33. Workflow recommandĂ© SERVEUR GIT GitHub / GitLab ^ | push | ┌────┮────┐ │ COMMIT │ └────┬────┘ ^ | git add ^ | MODIFICATIONS ^ | git pull | v SERVEUR GIT 34. RĂ©sumĂ© Pour travailler avec GitHub ou GitLab sous Windows, la configuration recommandĂ©e est : Git + HTTPS + Personal Access Token + Git Credential Manager + Visual Studio Code Une fois la configuration terminĂ©e, le workflow quotidien se limite gĂ©nĂ©ralement aux commandes suivantes : git pull git add . git commit -m "Description de la modification" git push Configuration recommandĂ©e : utiliser HTTPS avec un token disposant des permissions minimales nĂ©cessaires, laisser Git Credential Manager gĂ©rer l'authentification et ne jamais stocker manuellement le token dans .gitcredentials , une URL, un script ou un dĂ©pĂŽt Git.