Développement Web

Guide pratique : Git et GitHub pour débutants

22 min de lecture

Sommaire

Prérequis

  • Niveau : à l’aise avec un terminal de base (cd, ls, mkdir).
  • Outils : Git (gratuit, git-scm.com) + un compte GitHub gratuit. Optionnel : GitHub CLI ou GitHub Desktop.
  • Temps estimé : 2 heures pour parcourir le tutoriel et faire l’exercice final.

À quoi sert Git, et pourquoi tout le monde l’utilise

Git est un outil de versionnement créé par Linus Torvalds en 2005. Concrètement, il fait trois choses qui changent la vie d’un développeur. Premièrement, il garde un historique de toutes les versions de votre code, sauvegarde après sauvegarde, ce qui permet de revenir à n’importe quel état antérieur en quelques secondes. Deuxièmement, il permet à plusieurs personnes de travailler sur le même projet sans s’écraser mutuellement. Troisièmement, il rend possible le travail asynchrone : chacun fait ses modifications dans son coin, puis on fusionne intelligemment.

Sans Git, il n’y a pas de portfolio crédible côté développeur. Les recruteurs en 2026 regardent systématiquement le profil GitHub d’un candidat avant un entretien — qualité du code, fréquence des contributions, projets portés. Ne pas maîtriser Git aujourd’hui, c’est l’équivalent professionnel de ne pas savoir envoyer un e-mail.

L’autre raison pratique : tous les outils modernes du développement (déploiement automatique, intégration continue, gestion d’environnements, infrastructures as code) supposent que votre code est versionné dans un dépôt Git. Sans cela, vous restez bloqué à un mode de travail manuel d’il y a vingt ans.

Git et GitHub : ce sont deux choses différentes

Le piège classique du débutant est de confondre les deux. Git est un logiciel installé sur votre machine ; GitHub est un site web qui héberge des dépôts Git.

Git GitHub
Logiciel installé sur votre PC Plateforme web (github.com)
Gère les versions de votre code Stocke et partage votre code en ligne
Fonctionne entièrement hors ligne Nécessite Internet
Créé par Linus Torvalds en 2005 Lancé en 2008, racheté par Microsoft en 2018
Logiciel libre et open-source Service avec offres gratuite et payantes

GitHub n’est pas la seule option pour héberger un dépôt Git. GitLab et Bitbucket offrent des services équivalents avec des philosophies un peu différentes. Mais GitHub reste l’incontournable pour un développeur qui veut être visible — c’est là que se trouve l’écrasante majorité des projets open-source actifs.

Comprendre la séparation entre les deux outils permet aussi de saisir une chose contre-intuitive : on peut faire du Git sans jamais ouvrir GitHub, et inversement, GitHub propose des fonctionnalités (Issues, Discussions, Actions, Codespaces) qui n’existent pas dans Git lui-même.

Installer Git et faire la configuration de départ

L’installation diffère selon votre système. Sur Windows, télécharger l’installeur depuis git-scm.com et accepter les options par défaut suffit. Sur macOS, brew install git via Homebrew ou la commande xcode-select --install qui propose Git en bonus. Sur Linux Ubuntu/Debian, sudo apt install git. Sur Fedora, sudo dnf install git.

Vérifier que l’installation a réussi avec :

git --version

La sortie doit afficher quelque chose comme git version 2.45.0 ou plus récent. En 2026, toute version de Git inférieure à 2.40 est obsolète et doit être mise à jour, notamment pour bénéficier des commandes modernes git switch et git restore.

Faire ensuite la configuration globale, à exécuter une seule fois sur la machine. Cette étape est obligatoire — Git refuse de créer un commit tant qu’elle n’est pas faite :

git config --global user.name "Votre Nom"
git config --global user.email "votre.email@example.com"
git config --global init.defaultBranch main
git config --global pull.rebase false
git config --global core.autocrlf input

Les trois dernières lignes sont importantes. init.defaultBranch main fait que toute nouvelle initialisation crée une branche main par défaut au lieu de l’historique master. pull.rebase false choisit le comportement de fusion classique (plus prévisible pour un débutant) à la place du rebase automatique. core.autocrlf input évite les soucis de fins de lignes Windows quand on collabore avec des collègues sur Linux ou Mac.

Vérifier la configuration en cours avec git config --list --global qui affiche toutes les options actives.

Authentification GitHub : SSH ou jeton, pas mot de passe

Depuis 2021, GitHub n’accepte plus le mot de passe utilisateur pour les opérations Git en HTTPS. Deux mécanismes les remplacent : la clé SSH et le jeton d’accès personnel. Comprendre la différence évite des heures perdues à la première synchronisation.

La clé SSH est une paire cryptographique générée localement. La clé publique est déposée chez GitHub, la clé privée reste sur votre machine. À chaque opération Git (push, pull, clone), GitHub vérifie qu’une réponse cryptographique correcte arrive du couple. Avantage : pas de mot de passe à taper, pas de durée d’expiration, ça fonctionne tant que la clé reste sur la machine. Inconvénient : la clé privée volée donne accès au compte ; protéger avec une passphrase.

Le jeton d’accès personnel (Personal Access Token, PAT) est un long mot de passe à durée limitée que vous générez depuis GitHub. Vous l’utilisez à la place du mot de passe lors d’une opération HTTPS. Depuis 2022, GitHub propose les jetons « fine-grained » qui limitent strictement la portée (lecture seule, dépôts précis, durée courte). Plus sûr qu’un PAT classique mais plus lourd à gérer.

Pour démarrer en 2026, l’option recommandée est SSH parce qu’elle est plus simple sur la durée. Voici la procédure complète.

# Générer une nouvelle clé SSH (algorithme moderne ed25519)
ssh-keygen -t ed25519 -C "votre.email@example.com"

Appuyer sur Entrée pour accepter l’emplacement par défaut (~/.ssh/id_ed25519). Saisir une passphrase robuste — c’est un mot de passe qui chiffre la clé privée sur le disque. La machine de travail mémorise la passphrase via un agent SSH, vous ne la retapez pas à chaque commande.

Récupérer la clé publique pour la coller chez GitHub :

# Linux / macOS
cat ~/.ssh/id_ed25519.pub

# Windows (Git Bash)
cat ~/.ssh/id_ed25519.pub

Copier la sortie complète (qui commence par ssh-ed25519 AAAA... et finit par votre e-mail). Aller sur GitHub → Settings → SSH and GPG keys → New SSH key, coller, donner un nom descriptif (ex : « Laptop perso 2026 »), et confirmer.

Tester la connexion :

ssh -T git@github.com

La sortie doit afficher Hi votreusername! You've successfully authenticated, but GitHub does not provide shell access. Si une erreur apparaît, vérifier que l’agent SSH tourne (ssh-add -l) et y ajouter la clé (ssh-add ~/.ssh/id_ed25519).

À partir de là, utiliser les URLs SSH (git@github.com:user/repo.git) plutôt que les HTTPS pour clone, push et pull. La différence se voit au prefix : git@ pour SSH, https:// pour HTTPS.

Les commandes du quotidien

Ces dix commandes couvrent 90 % de l’usage en première année. Les maîtriser permet de devenir autonome.

Initialiser un projet. Dans un dossier existant ou nouveau, transformer un dossier ordinaire en dépôt Git suivi.

mkdir mon-projet
cd mon-projet
git init

Un dossier caché .git apparaît — c’est lui qui contient toute la base de données Git. Ne jamais le supprimer ni l’éditer à la main. Le supprimer reviendrait à perdre tout l’historique du projet.

Voir l’état des fichiers. Avant chaque opération, prendre l’habitude de demander à Git ce qu’il voit :

git status

La sortie liste les fichiers modifiés, les nouveaux fichiers, ce qui est prêt pour un commit. Les couleurs indiquent l’état : rouge pour les modifications non encore ajoutées, vert pour celles préparées au prochain commit. Cette commande est gratuite — l’utiliser dix fois par session ne ralentit rien.

Ajouter des fichiers au prochain commit. L’étape add dit à Git : « ces modifications-là, je veux les inclure dans la prochaine sauvegarde ».

git add index.html               # un fichier précis
git add src/                     # tout un dossier
git add .                        # tout ce qui a changé
git add -p                       # mode interactif, choisir morceau par morceau

Le mode -p (patch) est sous-utilisé par les débutants alors qu’il transforme la qualité des commits — il propose chaque morceau modifié et demande s’il faut l’inclure ou non. Pratique quand on a fait deux choses dans le même fichier et qu’on veut les commiter séparément.

Créer un commit (sauvegarde). Le commit est l’unité de base — un point de sauvegarde nommé.

git commit -m "Ajout du formulaire de contact avec validation"

Le message doit être lisible. Convention solide : verbe à l’impératif, objet précis, moins de 70 caractères. Mauvais exemples : « update », « fix », « WIP ». Bons exemples : « Corrige bug d’affichage mobile sur le footer », « Ajoute la validation côté serveur sur l’API contact ». Les Conventional Commits (préfixes feat:, fix:, docs:) sont une convention populaire pour les équipes qui veulent générer des changelogs automatiquement.

Voir l’historique. Trois variantes utiles selon le besoin.

git log                          # détaillé
git log --oneline                # une ligne par commit
git log --oneline --graph --all  # avec graphe visuel des branches

La troisième forme est précieuse pour comprendre une situation : elle dessine en ASCII les bifurcations de branches et leurs fusions. Indispensable quand un projet a plusieurs branches actives en parallèle.

Modifier le dernier commit. Si on s’aperçoit qu’un fichier manquait, ou que le message du commit était mauvais :

git add fichier-oublie.txt
git commit --amend --no-edit                    # ajoute au dernier commit, garde le message
git commit --amend -m "Nouveau message correct" # change le message

À ne JAMAIS utiliser sur un commit déjà poussé sur GitHub si d’autres personnes ont récupéré l’historique — cela réécrit l’historique partagé et casse les copies des autres.

Branches, fusions et résolution de conflits

Une branche est une ligne d’historique parallèle. Elle permet d’isoler un travail (nouvelle fonctionnalité, correction de bug, expérimentation) sans toucher à la branche principale. Quand le travail est terminé et validé, on fusionne dans main.

Les commandes modernes pour gérer les branches sont switch et restore, introduites avec Git 2.23 en 2019. checkout reste valide mais combine deux usages très différents (changer de branche / restaurer un fichier), source de confusion. Préférer désormais :

git switch nom-de-la-branche                 # changer de branche
git switch -c nouvelle-branche               # créer ET basculer
git switch -                                 # revenir à la branche précédente

git restore fichier.html                     # annuler les modifications locales d'un fichier
git restore --staged fichier.html            # retirer du prochain commit (ne supprime pas la modif)

Lister les branches existantes avec git branch (locales) ou git branch -a (locales + distantes).

Fusionner deux branches. Une fois le travail terminé sur une branche, on revient sur main et on fusionne :

git switch main
git pull                       # récupérer les éventuelles modifications du serveur
git merge nouvelle-fonctionnalite
git push                       # publier le résultat
git branch -d nouvelle-fonctionnalite  # supprimer la branche locale fusionnée

Si Git détecte que les deux branches ont modifié les mêmes lignes, il ne sait pas trancher et déclenche un conflit de fusion. C’est normal et ça arrive régulièrement.

Résoudre un conflit. Git annonce le conflit et marque les fichiers concernés. Ouvrir chaque fichier, repérer les marqueurs et choisir la version voulue :

<<<<<<< HEAD
<h1>Bienvenue sur mon site</h1>
=======
<h1>Bienvenue chez ITSkillsCenter</h1>
>>>>>>> branche-collegue

La partie entre <<<<<<< HEAD et ======= est votre version actuelle. La partie entre ======= et >>>>>>> branche-collegue est la version venue de l’autre branche. Garder ce qu’il faut, supprimer les marqueurs, sauvegarder. Puis :

git add fichier-en-conflit.html
git commit                     # un message par défaut "Merge branch ..." est proposé

VS Code, JetBrains et tout IDE moderne offrent une interface graphique pour ces résolutions, avec des boutons « Accept Current », « Accept Incoming », « Accept Both ». Ne pas hésiter à les utiliser tant qu’on apprend.

Le workflow Pull Request expliqué étape par étape

La Pull Request (souvent abrégée PR) est le rituel central du travail en équipe sur GitHub. Au lieu de fusionner directement votre branche dans main, vous proposez la fusion à l’équipe via une interface qui permet la revue de code, la discussion, les tests automatisés et l’approbation explicite.

Voici le cycle complet, étape par étape.

1. Récupérer l’état le plus à jour. Avant de commencer un nouveau travail :

git switch main
git pull

2. Créer une branche de travail. Le nom décrit la nature du travail :

git switch -c feat/formulaire-contact

Préfixes courants : feat/ pour une nouvelle fonctionnalité, fix/ pour une correction de bug, docs/ pour de la documentation, chore/ pour de la maintenance.

3. Coder et commiter. Faire le travail, par petits commits cohérents :

git add src/components/ContactForm.jsx
git commit -m "feat: ajoute le composant ContactForm avec validation"

git add src/styles/contact.css
git commit -m "feat: style le formulaire de contact"

4. Pousser la branche sur GitHub. Au premier push d’une branche neuve, ajouter -u origin nom-branche pour que les pulls suivants soient liés automatiquement :

git push -u origin feat/formulaire-contact

5. Ouvrir la Pull Request. Sur l’interface GitHub, un bandeau apparaît proposant de créer la PR depuis la branche poussée. Cliquer dessus et remplir :

  • Titre clair, ex : « feat: formulaire de contact avec validation côté client ».
  • Description structurée : ce qui change, pourquoi, comment tester, captures d’écran si UI.
  • Reviewers : assigner un ou plusieurs collègues.
  • Labels : tags qui organisent les PR (bug, feature, documentation, etc.).

6. Revue, échanges, ajustements. Les reviewers laissent des commentaires ligne par ligne. À chaque ajustement, faire un commit sur la même branche et pousser — la PR se met à jour toute seule.

7. Fusion. Une fois la PR approuvée et les tests automatisés au vert, le bouton « Merge » devient actif. Trois modes de fusion existent :

  • Merge commit : crée un commit de fusion qui garde l’historique exact. Idéal pour un projet qui veut tracer chaque étape.
  • Squash and merge : compacte tous les commits de la PR en un seul. Idéal pour garder un historique propre sur main.
  • Rebase and merge : rejoue les commits par-dessus main. Garde un historique linéaire sans commit de fusion.

Choisir selon la culture du projet ; les équipes qui veulent un main propre privilégient « Squash and merge ».

8. Nettoyer. Après fusion, supprimer la branche distante (bouton « Delete branch » dans l’interface GitHub) et la branche locale :

git switch main
git pull
git branch -d feat/formulaire-contact

Annuler une bêtise : reset, revert, restore, stash

Git pardonne presque tout — si on connaît la bonne commande. Quatre situations classiques.

J’ai modifié un fichier et je veux annuler. Tant que les modifications ne sont pas committées :

git restore fichier.html

J’ai fait git add et je veux retirer le fichier sans perdre la modif.

git restore --staged fichier.html

J’ai fait un commit que je veux annuler en gardant les modifications.

git reset --soft HEAD~1

Le commit disparaît, les modifications restent dans la zone d’index. Utile quand on veut refaire le commit avec un meilleur message ou en plusieurs morceaux.

J’ai fait un commit que je veux annuler complètement.

git reset --hard HEAD~1

Le commit ET les modifications disparaissent. À utiliser avec précaution — c’est la commande qui détruit du travail. Vérifier git status avant pour confirmer que rien d’important n’est en cours.

J’ai poussé un commit et je veux le retirer côté GitHub. Si le commit est déjà partagé, NE PAS utiliser git reset qui réécrit l’historique. Utiliser git revert qui crée un nouveau commit qui annule les changements :

git revert abc1234
git push

L’historique reste intact, les modifications sont annulées par un commit additionnel — propre, traçable, sans casser les copies des collègues.

J’ai des modifications en cours et je veux les mettre de côté pour basculer sur autre chose. Le stash est fait pour ça :

git stash                       # sauvegarde temporaire
git switch autre-branche        # bascule
# ... travail urgent ...
git switch ma-branche
git stash pop                   # récupère les modifications mises de côté

Le stash peut empiler plusieurs sauvegardes. git stash list les liste, git stash apply stash@{2} récupère la troisième.

GitHub CLI (gh) : ce qui change quand on quitte la souris

GitHub CLI est un outil en ligne de commande développé par GitHub depuis 2020 qui permet de faire les opérations habituellement faites via l’interface web — sans quitter le terminal. Pour un développeur qui passe ses journées sur le clavier, c’est un gain de temps réel.

L’installation se fait via les gestionnaires habituels :

# macOS
brew install gh

# Windows (avec winget)
winget install GitHub.cli

# Linux (Debian/Ubuntu)
sudo apt install gh

Après installation, s’authentifier une fois :

gh auth login

Le CLI propose plusieurs méthodes — choisir « GitHub.com », « SSH » comme protocole, suivre les instructions à l’écran. Une fenêtre de navigateur s’ouvre pour confirmer l’authentification, puis le CLI est utilisable.

Quelques commandes courantes :

# Cloner un dépôt sans coller l'URL complète
gh repo clone votreuser/mon-projet

# Créer un nouveau dépôt depuis un dossier local
gh repo create mon-nouveau --private --source=. --push

# Ouvrir une Pull Request depuis la branche courante
gh pr create --title "feat: ajout du formulaire" --body "Description..."

# Voir le statut des PR du dépôt
gh pr list

# Faire la revue d'une PR
gh pr review 42 --approve
gh pr review 42 --request-changes --body "Petit souci ligne 12"

# Fusionner une PR (une fois approuvée)
gh pr merge 42 --squash --delete-branch

# Voir les dernières exécutions d'Actions
gh run list
gh run view 123456

Le CLI ne remplace pas Git — il l’enrichit en ajoutant les opérations spécifiques à GitHub (PR, Issues, Actions, Releases). Pour les commandes Git proprement dites (commit, push, branch), continuer à utiliser git.

Sécurité de base en 2026 : 2FA, secrets, commits signés

Trois pratiques minimales pour éviter les accidents qui font mal.

Activer la double authentification. Sur GitHub → Settings → Password and authentication → Two-factor authentication. Préférer une application TOTP (Authy, 1Password, Bitwarden, Google Authenticator) plutôt qu’un SMS — les SMS sont vulnérables au SIM-swapping. Depuis fin 2023, GitHub impose la 2FA sur tous les comptes qui contribuent à du code, ce qui est une bonne chose.

Ne jamais committer de secret. Les fichiers .env, les clés d’API, les mots de passe, les jetons : tout cela doit aller dans le .gitignore AVANT le premier commit. Un secret poussé sur GitHub doit être considéré comme compromis même si le commit est supprimé après — l’historique Git public le garde, et des bots scannent les dépôts publics en permanence à la recherche de tels accidents. Si un secret a été poussé, le révoquer immédiatement dans le service concerné et générer un nouveau.

Pour se prémunir, mettre en place dès le démarrage un fichier .gitignore solide :

# Variables d'environnement
.env
.env.local
.env.*.local

# Dépendances
node_modules/
vendor/
__pycache__/

# Build
dist/
build/
*.pyc

# IDE
.vscode/
.idea/

# OS
.DS_Store
Thumbs.db

# Logs
*.log

GitHub propose le service Secret Scanning gratuit pour les dépôts publics qui détecte automatiquement les secrets connus (clés AWS, Stripe, OpenAI, etc.) et alerte. À activer dans les paramètres de chaque dépôt.

Signer ses commits. Un commit non signé peut afficher n’importe quel user.name — rien n’empêche un attaquant de pousser un commit qui semble venir de vous. La signature cryptographique des commits prouve qu’ils viennent bien de votre clé. Depuis Git 2.34, on peut signer avec sa clé SSH (plus simple que GPG). Sur GitHub :

# Configurer la signature SSH
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Puis dans GitHub → Settings → SSH and GPG keys → New SSH key, ajouter la même clé publique mais avec le type « Signing Key » au lieu de « Authentication Key ». À partir de là, chaque commit affichera un badge « Verified » sur GitHub, prouvant son authenticité.

Erreurs fréquentes du débutant et comment s’en sortir

Pousser des secrets sur GitHub.
Cause : commit d’un .env, d’une clé API ou d’un mot de passe.
Solution : ajouter ces fichiers à .gitignore AVANT le premier commit. Si déjà poussé, considérer la clé compromise et la régénérer immédiatement (l’historique Git public la garde même après suppression).

git push rejeté avec « non-fast-forward ».
Cause : quelqu’un a poussé avant vous, votre branche locale est en retard.
Solution : git pull --rebase pour rejouer vos commits par-dessus, puis git push. N’utiliser --force qu’en dernier recours et JAMAIS sur main — ça détruit le travail des autres.

Conflit de fusion qui fait peur.
Cause : deux branches modifient les mêmes lignes.
Solution : ouvrir chaque fichier marqué « both modified » dans VS Code, choisir « Accept Current / Incoming / Both », puis git add + git commit. Rester calme, c’est normal.

checkout qui prête à confusion.
Cause : git checkout faisait deux choses très différentes (changer de branche, restaurer un fichier).
Solution : depuis Git 2.23, préférer git switch <branche> et git restore <fichier>. checkout reste valide mais devient secondaire.

Authentification refusée à chaque push.
Cause : authentification HTTPS sans jeton, ou SSH avec clé non chargée dans l’agent.
Solution : passer en SSH (cf. section auth) ou ajouter la clé à l’agent avec ssh-add ~/.ssh/id_ed25519.

Le mauvais user.name dans les commits.
Cause : configuration Git globale différente de l’identité GitHub.
Solution : vérifier avec git config user.name et corriger avec git config --global user.name "Bon Nom". Les commits déjà faits gardent l’ancien nom — utiliser git rebase -i pour les corriger si nécessaire.

git pull qui efface des modifications locales.
Cause : modifications non committées écrasées par la mise à jour distante.
Solution : prendre l’habitude de git status avant chaque pull. En cas de modifications en cours, git stash pour les mettre de côté avant git pull, puis git stash pop.

Exercice pratique pour valider tout le tutoriel

L’apprentissage de Git ne tient qu’à la pratique. Le défi suivant couvre tout ce qui précède en une heure.

  1. Installer Git et créer un compte GitHub si ce n’est pas déjà fait.
  2. Configurer la clé SSH selon la procédure de la section authentification.
  3. Sur le terminal, créer un dossier mon-premier-projet avec un fichier index.html contenant un titre et un paragraphe.
  4. Initialiser Git, faire un premier commit « feat: structure HTML initiale ».
  5. Modifier le HTML, faire un deuxième commit. Refaire encore une fois pour avoir trois commits.
  6. Sur GitHub, créer un nouveau dépôt vide nommé mon-premier-projet.
  7. Lier le dépôt local au dépôt distant via SSH et pousser : git remote add origin git@github.com:votreuser/mon-premier-projet.git puis git push -u origin main.
  8. Créer une branche feat/style, ajouter un fichier style.css, faire un commit.
  9. Pousser la branche, créer une Pull Request via l’interface GitHub.
  10. Fusionner la PR avec « Squash and merge », supprimer la branche distante.
  11. Localement, basculer sur main, faire git pull, supprimer la branche locale.
  12. Activer la 2FA sur le compte GitHub, configurer la signature SSH, refaire un commit pour vérifier le badge « Verified ».

Si chaque étape passe sans assistance, vous êtes opérationnel sur Git pour vos projets personnels et professionnels en équipe.

Aide-mémoire et ressources

Commande Action
git init Initialiser un nouveau dépôt
git status Voir l’état des fichiers
git add . Préparer toutes les modifications
git add -p Préparer morceau par morceau
git commit -m "msg" Créer un commit
git commit --amend Modifier le dernier commit
git log --oneline --graph Historique visuel compact
git switch nom Changer de branche
git switch -c nom Créer et basculer sur une branche
git restore fichier Annuler les modifs locales d’un fichier
git restore --staged f Retirer un fichier de l’index
git merge branche Fusionner une branche dans la courante
git push Envoyer sur le dépôt distant
git pull Récupérer les modifs distantes
git stash Mettre les modifs de côté
git revert abc1234 Annuler un commit poussé
gh pr create Ouvrir une Pull Request en CLI
gh pr merge --squash Fusionner une PR en CLI

Ressources externes :

Lectures internes complémentaires :

#git #github #versioning
Service ITSkillsCenter

Application mobile Android et iOS

Création d'application mobile Android et iOS. À partir de 350 000 FCFA.

Démarrer mon projet
Publicité

Articles Similaires