« projet-final-v2-VRAIMENT-final.zip » ? C’est terminé. Dans ce guide Git et GitHub pour débutant, tu installes Git, configures ton identité, crées une clé SSH, relies ton poste à GitHub et publies ton premier projet. En 15 minutes, ton ordinateur est prêt à travailler comme dans une vraie équipe de développement.
Tu as entendu parler de Git et GitHub partout, mais tu ne sais pas par où commencer ? Ce guide Git et GitHub pour débutant est fait pour toi. On ne va pas apprendre cinquante commandes : on va configurer ton poste correctement, une bonne fois pour toutes, puis envoyer ton premier projet sur GitHub. C’est cette configuration de départ qui évite 90 % des galères des débutants.
- Ce que sont Git et GitHub, et pourquoi ce n’est pas la même chose.
- Installer Git avec les bonnes options sous Windows, macOS et Linux.
- Configurer ton identité, ta branche par défaut et ton éditeur.
- Créer une clé SSH et la relier à ton compte GitHub.
- Publier ton premier projet et récupérer celui d’un autre.
Git et GitHub : quelle différence ?
C’est la première source de confusion, alors clarifions tout de suite :
| Git | GitHub | |
|---|---|---|
| C’est quoi ? | Un logiciel de gestion de versions | Un site web qui héberge des dépôts Git |
| Où ça tourne ? | Sur ton ordinateur | Sur Internet |
| À quoi ça sert ? | Garder l’historique de ton code, revenir en arrière, travailler en parallèle | Sauvegarder tes projets en ligne, collaborer, montrer ton travail |
| Fonctionne sans l’autre ? | Oui, totalement | Non, il repose sur Git |
| Alternatives | Mercurial, SVN (peu utilisés aujourd’hui) | GitLab, Bitbucket, Codeberg |
Une image simple : Git est l’appareil photo qui prend des clichés de ton projet à chaque étape (les commits). GitHub est l’album en ligne où tu ranges ces clichés pour les sauvegarder et les partager.
Parce que Git est utilisé dans pratiquement toutes les entreprises de développement. Un recruteur qui voit un profil GitHub actif avec des projets bien tenus a une preuve concrète de tes compétences. Et pour toi, c’est la garantie de ne plus jamais perdre ton travail.
Étape 1 : installer Git
Sous Windows
Télécharge Git for Windows depuis git-scm.com et lance l’installateur. Il pose beaucoup de questions ; voici les choix recommandés pour un débutant :
| Écran de l’installateur | Choix recommandé | Pourquoi |
|---|---|---|
| Choosing the default editor | Use Visual Studio Code as Git’s default editor | Bien plus simple que Vim pour écrire tes messages |
| Adjusting the name of the initial branch | Override the default branch name → main | C’est le nom utilisé par GitHub |
| Adjusting your PATH environment | Git from the command line and also from 3rd-party software | Git utilisable dans PowerShell et VS Code |
| Choosing the SSH executable | Use bundled OpenSSH | Le plus simple |
| Configuring the line ending conversions | Checkout Windows-style, commit Unix-style | Évite les conflits de fins de ligne |
| Choose a credential helper | Git Credential Manager | Gère tes connexions HTTPS automatiquement |
| Les autres écrans | Laisse les valeurs par défaut | — |
L’installation ajoute aussi Git Bash, un terminal qui accepte les commandes Linux (ls, cat, touch). Tu peux utiliser au choix Git Bash, PowerShell ou le terminal de VS Code.
Sous macOS
Ouvre le Terminal et tape git --version. Si Git n’est pas installé, macOS propose d’installer les outils de développement en ligne de commande : accepte. Tu peux aussi l’installer avec Homebrew :
brew install gitSous Linux
# Debian, Ubuntu
sudo apt update && sudo apt install git
# Fedora
sudo dnf install gitVérifie l’installation dans un nouveau terminal :
git --version
# git version 2.x.xÉtape 2 : configurer ton identité
Chaque commit enregistre qui l’a fait. Git a besoin de ton nom et de ton adresse e-mail. Ces commandes ne sont à lancer qu’une seule fois par ordinateur :
git config --global user.name "Prénom Nom"
git config --global user.email "[email protected]"GitHub relie tes commits à ton compte grâce à l’adresse e-mail. Si elle est différente, tes contributions n’apparaîtront pas sur ton profil. Si tu ne veux pas exposer ton adresse personnelle dans l’historique public, GitHub te fournit une adresse anonyme du type [email protected] (dans Settings → Emails).
Étape 3 : les réglages que tout le monde devrait avoir
Quelques réglages supplémentaires rendent Git beaucoup plus agréable. Copie-colle ce bloc :
# Nom de la branche principale pour les nouveaux dépôts
git config --global init.defaultBranch main
# VS Code comme éditeur (messages de commit, fusions)
git config --global core.editor "code --wait"
# Couleurs dans le terminal
git config --global color.ui auto
# git pull : fusion classique (le comportement le plus simple à comprendre)
git config --global pull.rebase false
# Fins de ligne : true sous Windows, input sous macOS et Linux
git config --global core.autocrlf trueVérifie ta configuration complète :
git config --global --listWindows termine chaque ligne d’un fichier texte par deux caractères (CRLF), macOS et Linux par un seul (LF). Sans réglage, un même fichier modifié sur deux systèmes apparaît entièrement modifié dans Git. Avec core.autocrlf, Git convertit automatiquement : tes fichiers sont en CRLF sur ton Windows, mais enregistrés en LF dans le dépôt.
Étape 4 : créer ton compte GitHub
Va sur github.com et crée un compte gratuit. Quelques conseils :
- choisis un pseudo professionnel : il apparaîtra dans l’adresse de tous tes projets (
github.com/ton-pseudo) et tu le partageras sur ton CV ; - utilise la même adresse e-mail que dans
git config; - active la double authentification (2FA) dans Settings → Password and authentication, avec une application comme Google Authenticator, Microsoft Authenticator ou une clé de sécurité. GitHub l’exige de toute façon pour les comptes qui contribuent du code ;
- remplis ton profil : photo, courte biographie, lien vers ton site.
Étape 5 : relier ton poste à GitHub avec une clé SSH
Pour envoyer du code sur GitHub, ton ordinateur doit prouver qu’il agit en ton nom. Deux méthodes existent :
| HTTPS | SSH | |
|---|---|---|
| Adresse du dépôt | https://github.com/pseudo/projet.git | [email protected]:pseudo/projet.git |
| Authentification | Navigateur via Git Credential Manager | Une paire de clés sur ton poste |
| Configuration | Automatique à la première utilisation | 5 minutes, une seule fois |
| Mot de passe à chaque envoi | Non (mémorisé) | Non |
| Idéal pour | Démarrer très vite | Usage quotidien, plusieurs machines, serveurs |
Les deux fonctionnent très bien. On configure ici SSH, la méthode préférée des développeurs, que tu réutiliseras aussi pour te connecter à des serveurs.
Générer la clé
ssh-keygen -t ed25519 -C "[email protected]"Appuie sur Entrée pour accepter l’emplacement par défaut, puis choisis une phrase de passe (recommandé : elle protège ta clé si quelqu’un accède à ton ordinateur). Deux fichiers sont créés dans le dossier .ssh de ton dossier utilisateur :
id_ed25519: ta clé privée. Elle ne doit jamais quitter ton ordinateur ;id_ed25519.pub: ta clé publique, que tu vas donner à GitHub.
Ne l’envoie à personne, ne la copie pas dans un projet, ne la colle nulle part. Seul le fichier .pub (clé publique) peut être partagé. C’est comme un cadenas (public) et sa clé (privée) : tu peux distribuer des cadenas, mais tu gardes la clé.
Mémoriser la phrase de passe avec l’agent SSH
Pour ne pas retaper ta phrase de passe à chaque commande, on confie la clé à l’agent SSH.
Sous Windows (PowerShell en administrateur, une seule fois) :
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agentPuis, dans un PowerShell normal :
ssh-add $env:USERPROFILE\.ssh\id_ed25519Sous macOS et Linux :
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519Ajouter la clé publique sur GitHub
Affiche ta clé publique et copie-la entièrement :
# Windows (PowerShell)
Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub
# macOS / Linux
cat ~/.ssh/id_ed25519.pubSur GitHub : photo de profil → Settings → SSH and GPG keys → New SSH key. Donne-lui un nom (« PC portable »), colle la clé et valide.
Tester la connexion
ssh -T [email protected]La première fois, SSH demande de confirmer l’empreinte du serveur : tape yes. Tu dois voir :
Hi ton-pseudo! You've successfully authenticated, but GitHub does not provide shell access.🎉 Ton poste est relié à GitHub.
Étape 6 : ton premier dépôt Git
Créons un petit projet et suivons son historique. Dans un terminal :
mkdir mon-premier-projet
cd mon-premier-projet
git initgit init crée un dossier caché .git : c’est là que Git stocke tout l’historique. Crée maintenant un fichier README.md :
# Mon premier projet
Projet d'apprentissage de Git et GitHub.Puis regarde ce que Git en pense :
git statusGit indique que README.md est non suivi (untracked). Pour l’enregistrer dans l’historique, il y a deux temps :
git add README.md # 1. prépare le fichier (zone de préparation)
git commit -m "Ajoute le README" # 2. enregistre le cliché avec un message| Zone | Rôle | Commande pour y entrer |
|---|---|---|
| Répertoire de travail | Tes fichiers tels que tu les modifies | — |
| Zone de préparation (staging) | Les modifications choisies pour le prochain commit | git add |
| Historique (dépôt local) | Les clichés enregistrés | git commit |
| Dépôt distant (GitHub) | La copie en ligne | git push |
La zone de préparation te permet de choisir précisément ce qui va dans un commit. Tu as corrigé un bug et commencé une nouvelle fonctionnalité dans la même heure ? Tu peux en faire deux commits séparés, avec deux messages clairs. Ton historique reste lisible.
Consulte l’historique :
git log --oneline
# a1b2c3d Ajoute le READMEÉtape 7 : le fichier .gitignore
Certains fichiers ne doivent jamais aller dans Git : dépendances téléchargées, fichiers de configuration avec des mots de passe, fichiers générés. Crée un fichier .gitignore à la racine du projet :
# Dépendances
node_modules/
vendor/
# Secrets et configuration locale
.env
*.key
# Fichiers système et éditeurs
.DS_Store
Thumbs.db
.vscode/
# Fichiers générés
dist/
build/
*.logSi un mot de passe ou une clé d’API est poussé sur GitHub, même pendant une minute, considère-le comme volé : des robots parcourent GitHub en permanence à la recherche de secrets. Change-le immédiatement. Le .gitignore est ta première ligne de défense.
GitHub propose des modèles de .gitignore tout prêts pour chaque langage lors de la création d’un dépôt.
Étape 8 : publier ton projet sur GitHub
Sur GitHub, clique sur + → New repository :
- nomme-le
mon-premier-projet; - choisis Public ou Private ;
- ne coche pas « Add a README » (tu en as déjà un) ;
- clique sur Create repository.
GitHub affiche alors les commandes à exécuter. Choisis l’adresse SSH et lance, dans ton projet :
git add .gitignore
git commit -m "Ajoute le .gitignore"
git remote add origin [email protected]:ton-pseudo/mon-premier-projet.git
git push -u origin maingit remote add origin …déclare l’adresse du dépôt distant sous le nomorigin;git push -u origin mainenvoie la branchemainet mémorise le lien : ensuite, un simplegit pushsuffira.
Rafraîchis la page GitHub : ton projet est en ligne. 🚀
Étape 9 : récupérer un projet existant
Pour travailler sur un projet déjà présent sur GitHub (le tien sur un autre ordinateur, ou celui d’un autre développeur), on le clone :
git clone [email protected]:ton-pseudo/mon-premier-projet.git
cd mon-premier-projetEt pour récupérer les dernières modifications d’un projet déjà cloné :
git pullLe cycle de travail quotidien
Une fois ton poste configuré, ton travail se résume presque toujours à ces quelques commandes :
git pull # 1. récupère les dernières modifications
# … tu codes …
git status # 2. vois ce qui a changé
git add . # 3. prépare les modifications
git commit -m "Ajoute le formulaire de contact" # 4. enregistre
git push # 5. envoie sur GitHubUn bon message dit ce que fait le commit, à l’impératif et de façon précise : « Corrige le calcul de la TVA sur les remises » plutôt que « fix » ou « modifs ». Dans six mois, c’est toi qui remercieras ton toi d’aujourd’hui.
Git et GitHub pour débutant : les 5 erreurs à éviter
Ces erreurs, presque tous les débutants les font. Les connaître dès le départ t’évitera bien des frustrations.
- Commiter trop rarement. Un commit énorme qui mélange dix modifications est impossible à relire et à annuler proprement. Commite dès qu’une petite étape fonctionne : une fonction terminée, un bug corrigé, un style ajusté.
- Travailler directement sur main. Dès que ton projet fonctionne, crée une branche pour chaque nouvelle fonctionnalité (
git switch -c nouvelle-page). Si l’expérience tourne mal,mainreste intacte. - Oublier le .gitignore. Le dossier
node_modulesouvendorenvoyé sur GitHub alourdit le dépôt de milliers de fichiers inutiles, et un fichier.envpublié expose tes mots de passe. Crée le.gitignoreavant le premier commit. - Ne pas lire les messages de Git. Git est bavard, mais ses messages sont utiles : quand une commande échoue, il propose souvent la solution dans sa réponse (« use git pull before pushing again »). Lis-les avant de chercher sur Internet.
- Paniquer et supprimer le dossier. Face à un conflit ou une erreur, le réflexe de supprimer le projet pour le recloner fait perdre le travail non envoyé. Avec Git, presque tout se rattrape :
git statusd’abord, puisgit logetgit reflogpour comprendre où tu en es.
Crée un dépôt de test sur GitHub, clone-le dans deux dossiers différents de ton ordinateur et simule le travail de deux personnes : modifie le même fichier des deux côtés, pousse, récupère, résous le conflit. En une demi-heure, tu comprendras la collaboration avec Git mieux qu’avec n’importe quelle théorie.
Dépannage
| Message | Cause | Solution |
|---|---|---|
Permission denied (publickey) | Clé SSH non ajoutée à GitHub ou à l’agent | Vérifie l’étape 5 et lance ssh-add |
Author identity unknown | Identité non configurée | Lance les deux commandes git config --global user.… |
failed to push some refs | GitHub contient des commits que tu n’as pas | git pull puis git push |
src refspec main does not match any | Aucun commit encore, ou branche nommée master | Fais un premier commit, ou vérifie la branche avec git branch |
remote origin already exists | Le dépôt distant est déjà déclaré | git remote set-url origin <nouvelle-adresse> |
| Tous les fichiers apparaissent modifiés | Fins de ligne | Vérifie core.autocrlf (étape 3) |
FAQ
Git et GitHub sont-ils gratuits ?
Oui. Git est un logiciel libre et gratuit. GitHub offre gratuitement les dépôts publics et privés illimités, avec des fonctionnalités avancées réservées aux offres payantes, dont tu n’as pas besoin pour débuter.
Dois-je utiliser le terminal ou une interface graphique ?
Apprends les bases en ligne de commande : c’est universel et ça t’aide à comprendre ce qui se passe. Ensuite, utilise ce qui te convient. VS Code intègre un excellent panneau Git, et GitHub Desktop est très simple pour débuter.
Mon code est-il visible par tout le monde sur GitHub ?
Seulement si le dépôt est public. Un dépôt privé n’est visible que par toi et les personnes que tu invites. Tu peux changer ce réglage à tout moment dans les paramètres du dépôt.
J’ai fait une erreur dans mon dernier commit, comment la corriger ?
Si tu ne l’as pas encore envoyé sur GitHub, corrige les fichiers, fais git add, puis git commit --amend : le dernier commit est remplacé. S’il est déjà poussé, crée simplement un nouveau commit de correction.
Conclusion
Ton poste est maintenant configuré comme celui d’un développeur professionnel : Git installé avec les bonnes options, ton identité et tes réglages définis, une clé SSH reliée à GitHub et un premier projet publié. Ce travail, tu ne le referas plus jamais sur cet ordinateur.
Il ne te reste plus qu’à pratiquer : versionne chacun de tes projets, même les petits, et fais des commits réguliers avec des messages clairs. Tu cherches un projet à versionner pour t’entraîner ? Notre guide WordPress en local avec Docker est un bon candidat : tu pourras suivre chaque modification de ton thème avec Git. La documentation officielle de Git (le livre Pro Git, gratuit et en français) est la référence pour aller plus loin.
