Git et GitHub pour débutant : le guide pratique, de la première commande à la pull request

L’essentiel en une minute

Git et GitHub ne sont pas la même chose : Git est un logiciel installé sur votre ordinateur qui enregistre l’historique de vos fichiers, GitHub est un service en ligne qui héberge des dépôts Git et sert à collaborer. On peut utiliser Git sans GitHub, pas l’inverse : même quand vous modifiez un fichier dans le navigateur, c’est Git qui enregistre le commit côté GitHub.

Ce guide suit un vrai parcours de débutant : installation, premiers commits, branches, publication, pull request, conflit et retour en arrière. Chaque séquence de commandes, hors commandes visant GitHub, a été exécutée d’un bout à l’autre, dans l’ordre de l’article, dans un dépôt d’essai sous Git Bash, et les sorties affichées sont les vraies, en anglais comme vous les verrez (seuls les chemins et l’adresse e-mail sont anonymisés). Les faits sur GitHub viennent de sa documentation officielle, consultée les 1er et 2 novembre 2026.

Points clés

• Git enregistre l’historique en local ; GitHub, GitLab ou Codeberg hébergent une copie partagée de ce dépôt.
• Le cycle de base tient en quatre commandes : git status, git add, git commit, git push.
• GitHub n’accepte plus le mot de passe du compte pour les opérations Git depuis le 13 août 2021 : il faut une clé SSH, un token ou Git Credential Manager.
• git revert annule un commit déjà publié sans réécrire l’historique ; git reset est réservé aux commits restés sur votre machine.
• Les messages d’erreur de Git donnent presque toujours la commande à lancer : lisez les lignes hint:.

---

Git et GitHub : quelle différence ?

Git est l’outil, GitHub est l’un des endroits où l’on range ce que l’outil produit. Git est un système de contrôle de version distribué : chaque copie d’un dépôt contient tout l’historique, et la plupart des commandes fonctionnent sans connexion. GitHub, GitLab et Codeberg ajoutent par-dessus un hébergement, une interface web, les pull requests (appelées merge requests sur GitLab), le suivi des tickets et l’intégration continue.

GitLab peut s’installer sur vos propres serveurs : sa page d’installation décrit une instance « gérée par vous » avec un « contrôle total de vos données et de votre infrastructure » (notre traduction, GitLab, consulté le 1er novembre 2026). Codeberg se présente comme une plateforme à but non lucratif gérée par Codeberg e.V., association enregistrée à Berlin, et fonctionne avec le logiciel Forgejo (documentation de Codeberg, consultée le 1er novembre 2026). Les commandes de ce guide sont les mêmes sur les trois services.

GitHub publie chaque année ses propres chiffres. Selon son rapport Octoverse 2026, publié le 28 octobre 2026, la plateforme compte plus de 225 millions de développeurs, dont 4,75 millions en France en septembre 2026, dixième des dix pays que liste le billet (GitHub Octoverse 2026, chiffres de l’éditeur). Le billet ne dit pas combien de ces développeurs sont actifs.

---

Installer Git et le configurer

La version stable de Git est la 2.56.0, publiée le 28 septembre 2026, et l’installeur Git for Windows en est à la révision 2.56.0(4), publiée le 26 octobre 2026 (git-scm.com, relu le 2 novembre 2026). Selon votre système :

• Windows : téléchargez Git for Windows sur git-scm.com. Il installe aussi Git Bash, un terminal où les commandes de ce guide fonctionnent telles quelles.
• macOS : parmi les options que liste git-scm.com, les outils en ligne de commande Xcode (xcode-select --install) ou Homebrew (brew install git).
• Linux : passez par le gestionnaire de paquets, par exemple sudo apt install git sur Ubuntu ou Debian. Si le terminal vous est étranger, commencez par nos commandes Linux de base.

Configurez ensuite votre identité, une seule fois par machine. Git l’inscrit dans chaque commit. Pour que GitHub rattache vos commits à votre profil, utilisez une adresse de votre compte, ou l’adresse « no-reply » que GitHub fournit si vous voulez garder la vôtre privée (GitHub Docs). Voici la séquence exécutée, depuis un dossier projets, et sa sortie :

$ git --version
git version 2.53.0.windows.1
$ git config --global user.name "Alice Martin"
$ git config --global user.email [email protected]
$ git config --global init.defaultBranch main
$ git config --global --list
user.name=Alice Martin
[email protected]
init.defaultbranch=main

La troisième ligne fixe le nom de la branche principale à main. Sans elle, Git 2.53 crée encore une branche master et affiche cet avertissement à chaque git init (extrait) :

hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint:   git config --global init.defaultBranch <name>
…

Notre poste d’essai avait Git 2.53 et non la 2.56 : les sorties de ce guide viennent donc de la 2.53. Sous Windows, un avertissement sur les fins de ligne (LF et CRLF) peut aussi apparaître lors d’un git add : il est sans gravité, voir la liste des erreurs en fin d’article.

---

Les quatre zones à comprendre

Presque toutes les confusions de débutant viennent d’une seule idée : un fichier modifié n’est pas encore enregistré. Git distingue trois zones sur votre ordinateur, plus le dépôt distant.

1. Le répertoire de travail : vos fichiers, tels que vous les éditez.
2. La zone de préparation (index, ou staging area) : ce que vous avez choisi d’inclure dans le prochain commit, avec git add.
3. Le dépôt local : le dossier caché .git, où git commit range chaque version.
4. Le dépôt distant : la copie sur GitHub ou ailleurs, alimentée par git push et relue par git pull.

Un commit est une photo de l’état préparé, avec un auteur, une date, un message et un identifiant (le hash, dont git log --oneline affiche les premiers caractères, 7 en général). Une branche est un simple pointeur vers un commit, qui avance à chaque nouveau commit.

---

Premier dépôt : init, status, add, commit, log

Le réflexe à prendre est de lancer git status avant et après chaque commande : il dit où vous en êtes et suggère la suite. Lancé dans projets, qui n’est pas un dépôt, il répond par l’erreur la plus fréquente du premier jour :

$ git status
fatal: not a git repository (or any of the parent directories): .git

On crée donc le dépôt dans le dossier du projet, puis on ajoute un premier fichier :

$ mkdir mon-site
$ cd mon-site
$ git init
Initialized empty Git repository in C:/Users/alice/projets/mon-site/.git/
$ echo "# Mon site" > README.md
$ git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    README.md

nothing added to commit but untracked files present (use "git add" to track)

Le fichier est « untracked » : Git le voit mais ne le suit pas encore. git add le place dans la zone de préparation, git commit l’enregistre :

$ git add README.md
$ git status
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   README.md

$ git commit -m "Ajoute le README"
[main (root-commit) c90e6ad] Ajoute le README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
$ git log --oneline
c90e6ad Ajoute le README

Avant le tout premier commit, Git suggère git rm --cached pour retirer un fichier de la préparation ; ensuite, il suggère git restore --staged, comme on le verra plus bas. Un bon message dit ce que fait la modification : « Ajoute le formulaire de contact » plutôt que « modifs ». Un commit, une idée : c’est ce qui rend le retour en arrière possible.

---

Voir et annuler une modification : diff et restore

git diff montre ce qui a changé et n’est pas encore préparé, ligne par ligne. Les lignes ajoutées commencent par +, les lignes supprimées par - :

$ echo "Un site personnel en HTML." >> README.md
$ git diff
diff --git a/README.md b/README.md
index 7b538c8..803ccb1 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
 # Mon site
+Un site personnel en HTML.

git restore remet le fichier dans son dernier état préparé, ou dans son dernier état commité si rien n’est préparé. Attention : la modification annulée est perdue, sans corbeille.

$ git restore README.md
$ git status
On branch main
nothing to commit, working tree clean

Avec l’option --staged, la même commande retire un fichier de la zone de préparation sans toucher à son contenu. On crée une page d’accueil, on la prépare, on se ravise, puis on la prépare à nouveau et on l’enregistre :

$ echo "<h1>Bonjour</h1>" > index.html
$ git add index.html
$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    new file:   index.html

$ git restore --staged index.html
$ git status
On branch main
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    index.html

nothing added to commit but untracked files present (use "git add" to track)
$ git add index.html
$ git commit -m "Ajoute la page d'accueil"
[main cbc68b6] Ajoute la page d'accueil
 1 file changed, 1 insertion(+)
 create mode 100644 index.html

git restore et git switch remplacent les anciens usages de git checkout, que vous croiserez encore dans des tutoriels plus anciens.

---

Le fichier .gitignore

Un fichier .gitignore liste ce que Git doit ignorer : dépendances téléchargées, fichiers générés, et surtout secrets. Sans lui, un git add . distrait embarque un fichier .env qui contient vos clés d’API. La démonstration, avec un faux dossier de dépendances et un faux secret :

$ mkdir node_modules && echo "x" > node_modules/lib.js
$ echo "API_KEY=secret" > .env
$ git status --short
?? .env
?? node_modules/
$ printf 'node_modules/\n.env\n' > .gitignore
$ git status --short
?? .gitignore
$ git add .gitignore
$ git commit -m "Ajoute un .gitignore"
[main aba7ed7] Ajoute un .gitignore
 1 file changed, 2 insertions(+)
 create mode 100644 .gitignore

Après ajout du fichier, .env et node_modules/ disparaissent de la liste. Créez le .gitignore dès le premier commit : un fichier déjà suivi par Git reste suivi même si vous l’ajoutez ensuite au .gitignore. Il faut alors l’en retirer avec git rm --cached <fichier>, qui le laisse sur votre disque. GitHub publie des modèles par langage dans son dépôt github/gitignore.

Si un secret a déjà été poussé, le supprimer dans un nouveau commit ne suffit pas : il reste dans l’historique. Révoquez la clé et générez-en une nouvelle.

---

Les branches : branch, switch, merge

Une branche permet de travailler sur une fonctionnalité sans toucher à main, puis de l’y intégrer quand elle est prête. On la crée et on s’y place avec git switch -c :

$ git branch
* main
$ git switch -c contact
Switched to a new branch 'contact'
$ echo "<p>Contact : [email protected]</p>" >> index.html
$ git commit -am "Ajoute le contact"
[contact f24f440] Ajoute le contact
 1 file changed, 1 insertion(+)

L’option -a de git commit prépare automatiquement les fichiers déjà suivis qui ont changé ; elle ignore les nouveaux fichiers. On revient ensuite sur main et on fusionne :

$ git switch main
Switched to branch 'main'
$ git merge contact
Updating aba7ed7..f24f440
Fast-forward
 index.html | 1 +
 1 file changed, 1 insertion(+)
$ git branch -d contact
Deleted branch contact (was f24f440).

« Fast-forward » signifie que main n’avait pas bougé : Git a simplement avancé le pointeur. Quand les deux branches ont chacune de nouveaux commits, Git crée un commit de fusion, et s’ils touchent les mêmes lignes, il y a conflit (voir plus bas). Votre éditeur peut afficher tout cela graphiquement : notre sélection d’extensions VS Code en couvre plusieurs pour Git.

---

Publier sur GitHub sans mot de passe

Pour envoyer votre code sur GitHub, le mot de passe de votre compte ne marche pas. GitHub l’a annoncé ainsi : « À partir du 13 août 2021, nous n’accepterons plus les mots de passe de compte pour authentifier les opérations Git sur GitHub.com » (notre traduction, blog de GitHub). Sa documentation confirme que cette authentification a été retirée au profit de méthodes plus sûres (GitHub Docs, consulté le 1er novembre 2026).

Git Credential Manager est inclus dans Git for Windows et proposé par défaut pendant l’installation (documentation de GCM). Son dépôt le décrit comme un assistant d’identification appelé automatiquement par Git, qui réutilise les identifiants enregistrés tant qu’ils restent valides, sur Windows, macOS et Linux, pour GitHub, GitLab et Bitbucket entre autres (dépôt de GCM). GitHub le cite, avec GitHub CLI, comme alternative au token.

Le token personnel se crée dans les paramètres du compte, rubrique des paramètres pour développeurs. GitHub recommande les tokens « fine-grained » plutôt que les tokens « classic », et précise qu’on le saisit à la place du mot de passe pour les opérations Git en HTTPS (GitHub Docs). Donnez-lui une date d’expiration et uniquement les droits nécessaires.

La clé SSH se génère avec la commande que recommande la documentation de GitHub (GitHub Docs) :

$ ssh-keygen -t ed25519 -C "[email protected]"
Generating public/private ed25519 key pair.
…
The key fingerprint is:
SHA256:(empreinte masquée) [email protected]
…

Choisissez une phrase de passe. Copiez ensuite le contenu du fichier id_ed25519.pub (jamais celui sans extension, qui est la clé privée) dans les paramètres SSH de votre compte GitHub, puis vérifiez avec ssh -T [email protected]. À la première connexion, SSH demande de confirmer l’identité du serveur : comparez l’empreinte affichée avec celles que publie GitHub (empreintes des clés SSH de GitHub) avant de répondre yes.

En cas de succès, GitHub répond « Hi USERNAME! You’ve successfully authenticated, but GitHub does not provide shell access. » (GitHub Docs). Sans clé enregistrée, voici ce que nous avons obtenu :

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

Activez aussi la double authentification sur votre compte GitHub : notre guide sur la double authentification explique comment choisir la méthode.

---

Travailler avec un dépôt distant : push, pull, clone

Une fois authentifié, la publication tient en trois commandes. La documentation de GitHub conseille de créer le dépôt en ligne vide, sans README, licence ni .gitignore, pour éviter les erreurs quand on y pousse un projet existant (GitHub Docs). Avec GitHub, selon la méthode d’authentification choisie :

# En HTTPS (Git Credential Manager ou token)
git remote add origin https://github.com/votre-pseudo/mon-site.git
# Ou en SSH : utilisez cette ligne à la place de la précédente, jamais les deux
# git remote add origin [email protected]:votre-pseudo/mon-site.git

git remote -v
git push -u origin main

Pour ce guide, nous n’avons rien poussé sur GitHub : un dépôt local « nu », créé avec git init --bare à côté du projet, a joué le rôle du serveur. Les commandes et les messages sont les mêmes, seule l’adresse change :

$ git init --bare ../serveur/mon-site.git
Initialized empty Git repository in C:/Users/alice/projets/serveur/mon-site.git/
$ git remote add origin ../serveur/mon-site.git
$ git remote -v
origin  ../serveur/mon-site.git (fetch)
origin  ../serveur/mon-site.git (push)
$ git push -u origin main
To ../serveur/mon-site.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

L’option -u relie votre branche main à origin/main : ensuite, git push et git pull suffisent. Un collègue, ou vous-même sur un autre ordinateur, récupère le projet avec git clone, qui copie tout l’historique. Le collègue ajoute un pied de page et pousse :

$ cd ..
$ git clone serveur/mon-site.git copie-collegue
Cloning into 'copie-collegue'...
done.
$ cd copie-collegue
$ git log --oneline
f24f440 Ajoute le contact
aba7ed7 Ajoute un .gitignore
cbc68b6 Ajoute la page d'accueil
c90e6ad Ajoute le README
$ echo "<footer>2026</footer>" >> index.html
$ git commit -am "Ajoute un pied de page"
[main aa03f35] Ajoute un pied de page
 1 file changed, 1 insertion(+)
$ git push
To C:/Users/alice/projets/serveur/mon-site.git
   f24f440..aa03f35  main -> main

Pendant ce temps, vous avez fait votre propre commit dans mon-site. Votre git push est alors refusé, ce qui protège le travail du collègue :

$ cd ../mon-site
$ echo "Un site personnel en HTML." >> README.md
$ git commit -am "Complète le README"
[main 343ad23] Complète le README
 1 file changed, 1 insertion(+)
$ git push
To ../serveur/mon-site.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '../serveur/mon-site.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Le git pull suggéré échoue lui aussi la première fois, parce que Git veut savoir comment combiner les deux historiques :

$ git pull
From ../serveur/mon-site
   f24f440..aa03f35  main       -> origin/main
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
…
fatal: Need to specify how to reconcile divergent branches.

Pour débuter, choisissez la fusion (pull.rebase false), la plus simple à comprendre. Le pull crée alors un commit de fusion. Sans option, Git ouvre votre éditeur pour que vous validiez le message de ce commit (il suffit d’enregistrer et de fermer ; dans Vim, l’éditeur par défaut de Git pour Windows, tapez Échap puis :wq) ; l’option --no-edit accepte directement le message proposé :

$ git config --global pull.rebase false
$ git pull --no-edit
Merge made by the 'ort' strategy.
 index.html | 1 +
 1 file changed, 1 insertion(+)
$ git log --oneline --graph
*   5759bc0 Merge branch 'main' of ../serveur/mon-site
|\
| * aa03f35 Ajoute un pied de page
* | 343ad23 Complète le README
|/
* f24f440 Ajoute le contact
…
$ git push
To ../serveur/mon-site.git
   aa03f35..5759bc0  main -> main

Le bon réflexe en équipe : git pull avant de travailler et avant de pousser.

---

Pull request et revue de code

Une pull request est, selon GitHub, « une proposition de fusionner des modifications de code dans un projet » (notre traduction, GitHub Docs, consulté le 2 novembre 2026). Au lieu de fusionner vous-même dans main, vous poussez une branche et demandez qu’on la relise. Le déroulé :

1. Créez une branche : git switch -c formulaire-contact.
2. Faites vos commits, puis poussez la branche : git push -u origin formulaire-contact.
3. Sur GitHub, ouvrez une pull request depuis cette branche ; en général, un bandeau le propose dès le push. Rédigez un titre clair et une description : ce qui change, pourquoi, comment le vérifier.
4. Les relecteurs commentent ligne par ligne, approuvent ou demandent des changements. Vous corrigez par de nouveaux commits sur la même branche : la pull request se met à jour toute seule.
5. Une fois approuvée, la branche est fusionnée dans main, puis en général supprimée.

Une pull request en brouillon (« draft ») montre un travail inachevé : GitHub précise qu’elle ne peut pas être fusionnée (GitHub Docs). Pour une bonne revue, gardez les pull requests courtes, relisez votre propre diff avant l’envoi, et commentez le code, jamais la personne.

C’est aussi là que les tests automatiques s’exécutent : notre tutoriel GitHub Actions montre comment lancer les tests d’une API Node.js à chaque pull request.

Le volume donne une idée de la place de ce mécanisme. Le rapport Octoverse 2026 compte 1,3 milliard de pull requests fusionnées et 34,3 milliards de commits entre le 1er octobre 2025 et le 30 septembre 2026, dépôts publics et privés (GitHub Octoverse 2026, chiffres de l’éditeur). GitHub précise que les chiffres 2024 et 2025 du graphique ont été recalculés sur ces mêmes définitions et peuvent donc différer de ses rapports précédents, qui ne couvraient que l’activité publique, de septembre à août.

---

Résoudre un conflit de fusion

Un conflit survient quand deux branches modifient les mêmes lignes : Git ne choisit pas à votre place. Pour le provoquer, on change le titre en « Bienvenue » sur une branche titre, et en « Salut » sur main (sur macOS, sed -i s’écrit sed -i '' ; vous pouvez aussi modifier le titre dans votre éditeur) :

$ git switch -c titre
Switched to a new branch 'titre'
$ sed -i "s/Bonjour/Bienvenue/" index.html
$ git commit -am "Titre : Bienvenue"
[titre 8405e86] Titre : Bienvenue
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git switch main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
$ sed -i "s/Bonjour/Salut/" index.html
$ git commit -am "Titre : Salut"
[main e1eec83] Titre : Salut
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git merge titre
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
    both modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")

Git a écrit les deux versions dans le fichier, entre des marqueurs. La version de la branche courante (HEAD) est au-dessus de =======, celle de la branche fusionnée en dessous :

$ cat index.html
<<<<<<< HEAD
<h1>Salut</h1>
=======
<h1>Bienvenue</h1>
>>>>>>> titre
<p>Contact : [email protected]</p>
<footer>2026</footer>

Pour résoudre : ouvrez le fichier, gardez la bonne version (ou un mélange des deux), supprimez les trois lignes de marqueurs, puis signalez la résolution avec git add et terminez par un commit. C’est la procédure que décrit la documentation de GitHub. Ici, nous gardons « Bienvenue » en réécrivant le fichier :

$ printf '<h1>Bienvenue</h1>\n<p>Contact : [email protected]</p>\n<footer>2026</footer>\n' > index.html
$ git add index.html
$ git commit -m "Fusionne la branche titre"
[main b84f4d1] Fusionne la branche titre
$ git branch -d titre
Deleted branch titre (was 8405e86).

Vérifiez le fichier avant le git add : les lignes hors marqueurs doivent rester. Et si vous êtes perdu au milieu d’une fusion, git merge --abort remet tout comme avant.

---

Annuler une erreur sans danger

La règle d’or : on ne réécrit jamais un historique déjà poussé. Le livre officiel Pro Git la formule ainsi pour le rebase : « Ne rebasez pas des commits qui existent en dehors de votre dépôt et sur lesquels d’autres personnes ont pu baser leur travail » (notre traduction, Pro Git). Le même principe vaut pour git reset et git push --force. Dans les commandes ci-dessous, HEAD~1 désigne le commit précédent, et HEAD~4 le commit situé quatre crans en arrière.

git revert est l’outil sûr pour un commit publié. La documentation de Git le décrit comme une commande qui enregistre de nouveaux commits pour inverser l’effet de commits précédents (git-revert). Exemple avec un commit raté déjà poussé :

$ echo "Ligne ajoutée par erreur" >> README.md
$ git commit -am "Commit raté"
[main 252c6dc] Commit raté
 1 file changed, 1 insertion(+)
$ git push
To ../serveur/mon-site.git
   5759bc0..252c6dc  main -> main
$ git revert --no-edit HEAD
[main 13e43d9] Revert "Commit raté"
 Date: Mon Nov 2 10:08:33 2026 +0100
 1 file changed, 1 deletion(-)
$ git log --oneline -3
13e43d9 Revert "Commit raté"
252c6dc Commit raté
b84f4d1 Fusionne la branche titre
$ git push
To ../serveur/mon-site.git
   252c6dc..13e43d9  main -> main

Les deux commits restent visibles, et le push passe sans forcer. À l’inverse, git reset ne sert que pour ce qui n’a pas quitté votre machine. Le --soft défait un commit en gardant son contenu préparé ; le --hard jette les modifications des fichiers suivis, mais laisse en place un fichier non suivi, ici brouillon.txt :

$ echo "brouillon" > brouillon.txt
$ git add brouillon.txt
$ git commit -m "Brouillon local"
[main 03d0535] Brouillon local
 1 file changed, 1 insertion(+)
 create mode 100644 brouillon.txt
$ git reset --soft HEAD~1
$ git status --short
A  brouillon.txt
$ git restore --staged brouillon.txt
$ echo "<p>essai</p>" >> index.html
$ git status --short
 M index.html
?? brouillon.txt
$ git reset --hard
HEAD is now at 13e43d9 Revert "Commit raté"
$ git status --short
?? brouillon.txt
$ rm brouillon.txt

Dernier outil utile : git stash met de côté des modifications en cours pour changer de branche, et git stash pop les reprend. Par défaut, il ne prend que les fichiers suivis ; ajoutez -u pour embarquer aussi les nouveaux fichiers. Ici, une branche ancienne-version pointe sur un commit antérieur, où index.html est différent :

$ git switch -c ancienne-version HEAD~4
Switched to a new branch 'ancienne-version'
$ git switch main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
$ echo "<p>en cours</p>" >> index.html
$ git switch ancienne-version
error: Your local changes to the following files would be overwritten by checkout:
    index.html
Please commit your changes or stash them before you switch branches.
Aborting
$ git stash
Saved working directory and index state WIP on main: 13e43d9 Revert "Commit raté"
$ git switch ancienne-version
Switched to branch 'ancienne-version'
$ git switch main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
$ git stash pop
…
    modified:   index.html
…
Dropped refs/stash@{0} (…)

---

Aide-mémoire : 20 commandes Git

---

Les erreurs de débutant et leurs vrais messages

Tous ces messages ont été obtenus lors de notre essai, sauf le dernier. Entre parenthèses, la commande qui les a déclenchés.

• fatal: not a git repository (or any of the parent directories): .git (git status) : mauvais dossier, ou git init oublié.
• Author identity unknown puis fatal: unable to auto-detect email address (git commit) : configurez user.name et user.email.
• fatal: pathspec 'fichier-inexistant.txt' did not match any files (git add) : faute de frappe ou mauvais dossier.
• fatal: invalid reference: dev (git switch dev) : la branche n’existe pas ; créez-la avec git switch -c dev.
• fatal: No configured push destination. (git push) : aucun dépôt distant déclaré ; lancez git remote add origin <url>.
• nothing to commit, working tree clean (git commit) : rien de nouveau à enregistrer.
• error: src refspec main does not match any (git push -u origin main) : la branche main n’existe pas encore. Soit elle n’a aucun commit (notre cas), soit votre branche s’appelle master, le défaut de Git 2.53 sans réglage. git status affiche son nom sur la première ligne.
• ! [rejected] main -> main (fetch first) (git push) : faites git pull, puis git push.
• fatal: Need to specify how to reconcile divergent branches. (git pull) : git config --global pull.rebase false.
• error: Your local changes to the following files would be overwritten by checkout (git switch) : commitez ou utilisez git stash.
• warning: in the working copy of 'style.css', LF will be replaced by CRLF the next time Git touches it (git add sous Windows) : avertissement de fin de ligne, sans gravité.
• [email protected]: Permission denied (publickey). (ssh -T [email protected]) : aucune clé SSH reconnue ; ajoutez votre clé publique.
• ssh: connect to host github.com port 22: Connection timed out (ssh -T [email protected]) : souvent, un pare-feu ou le réseau bloque le port 22. GitHub documente une connexion par le port 443 (GitHub Docs), ou passez en HTTPS.
• remote: Support for password authentication was removed on August 13, 2021. (git push en HTTPS) : utilisez un token ou Git Credential Manager. Message rapporté sur le forum de GitHub, non reproduit ici.

---

Et ensuite ?

Git et GitHub deviennent vite un outil de carrière autant qu’un outil technique. Un historique propre et quelques projets publics sont la base d’un portfolio de développeur, et le lien vers votre profil GitHub a sa place dans un CV de développeur junior. En entretien technique, on vous demandera souvent d’expliquer une fusion ou la différence entre revert et reset.

Pour pratiquer, versionnez dès maintenant vos exercices : en suivant notre guide pour apprendre JavaScript ou celui pour apprendre Python, faites un commit à chaque exercice réussi et une branche par mini-projet.

---

Ce que nous n’avons pas pu vérifier

• Les sorties de Git 2.56. Notre poste avait Git 2.53.0 : un message peut avoir changé de formulation depuis.
• Les étapes sur GitHub.com. Aucun dépôt n’a été créé sur GitHub ; les libellés de l’interface web et la fenêtre de connexion de Git Credential Manager n’ont pas été vus.
• Le message d’erreur sur le mot de passe, tiré d’un témoignage de 2023 sur le forum de GitHub.
• macOS et Linux. Tout a été exécuté sous Windows, dans Git Bash.
• Les chiffres d’Octoverse, publiés par GitHub sur sa propre plateforme, sans audit tiers.

---

Questions fréquentes

Quelle est la différence entre Git et GitHub ?

Git est un logiciel de contrôle de version qui s’installe sur votre ordinateur et fonctionne hors ligne. GitHub est un service en ligne qui héberge des dépôts Git et ajoute la collaboration : pull requests, revues, tickets, GitHub Actions. On peut utiliser Git seul, ou avec GitLab ou Codeberg à la place de GitHub.

Faut-il apprendre Git avant GitHub ?

Oui. Les commandes add, commit, branch et merge sont celles de Git ; GitHub n’en est que la partie partagée. Maîtrisez le cycle local, puis publiez.

Pourquoi GitHub refuse-t-il mon mot de passe ?

Depuis le 13 août 2021, GitHub n’accepte plus le mot de passe du compte pour les opérations Git (blog de GitHub). Utilisez Git Credential Manager, inclus dans Git for Windows, un token personnel en HTTPS, ou une clé SSH.

Comment annuler un commit déjà poussé sur GitHub ?

Avec git revert <commit>, qui crée un nouveau commit inversant l’ancien, puis git push. Évitez git reset suivi d’un git push --force sur une branche partagée : vous réécririez un historique que d’autres ont peut-être déjà récupéré.

---

À propos de l’auteur

Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d’IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur.

Méthode. Guide fondé sur la documentation officielle de Git (git-scm.com, livre Pro Git), la documentation et le blog de GitHub, la documentation de Git Credential Manager, de GitLab et de Codeberg, consultées les 1er et 2 novembre 2026, et sur le rapport Octoverse 2026 de GitHub, dont les chiffres sont signalés comme ceux de l’éditeur. Les citations issues de sources en anglais sont traduites par nos soins. Aucun lien n’est affilié et aucune relation commerciale ne lie l’auteur aux services cités.

Ce qui a été exécuté. Le 2 novembre 2026, dans Git Bash sous Windows avec Git 2.53.0 et une configuration globale isolée, un seul script a rejoué depuis un dossier vide toutes les séquences de l’article dans leur ordre, de git config au conflit de fusion, à git revert, git reset, git stash et aux erreurs listées ; les sorties affichées viennent de cette exécution. Un dépôt local nu a remplacé GitHub ; aucun code n’a été poussé vers un service réel.

Le 1er novembre, ssh-keygen -t ed25519 (clé jetable, supprimée ensuite) et ssh -T [email protected] sans clé ont été lancés ; le 2 novembre, ce même test a expiré sur le port 22. Le message sur le mot de passe n’a pas été reproduit. Les hash dépendent de la date et de l’auteur : les vôtres seront différents.

Une erreur ou une commande qui a changé ? Écrivez à [email protected] : l’article sera corrigé et la date de mise à jour modifiée.

Dernière mise à jour : 2 novembre 2026.

Image : Paul (@causeimluap) sur Unsplash (Unsplash License).