Tutoriel Git : installer et configurer Git

Ce chapitre installe Git, règle les trois paramètres sans lesquels votre premier commit sera refusé, et met en place l’authentification auprès de GitHub ou GitLab. Comptez une quinzaine de minutes, la partie clé SSH comprise.

Si vous arrivez directement ici, la distinction entre Git et GitHub et le détail du parcours sont posés dans l’introduction du tutoriel.

Installer Git

Git est probablement déjà présent sur votre machine si vous êtes sous macOS ou Linux. Vérifiez avant d’installer quoi que ce soit :

git --version

Si la commande répond un numéro de version, Git est installé et vous pouvez passer à la configuration. Si elle répond que la commande est introuvable, suivez la section correspondant à votre système.

Windows

Le plus simple est le gestionnaire de paquets intégré à Windows :

winget install --id Git.Git -e --source winget

Sinon, téléchargez l’installateur sur git-scm.com/install/windows et laissez les options par défaut. La dernière version publiée au moment de cette vérification est Git for Windows 2.55.0(5), du 20 août 2026. L’installation fournit Git Bash, un terminal qui reproduit l’environnement Unix. Utilisez-le plutôt que l’invite de commandes : toutes les commandes de ce tutoriel y fonctionnent telles quelles.

macOS

Git est fourni avec les outils en ligne de commande de Xcode. La première invocation de git propose de les installer, ou vous pouvez forcer l’installation :

xcode-select --install

Cette version est fiable mais souvent en retard de quelques mois sur la version officielle. Pour rester à jour, passez par Homebrew :

brew install git

Linux

Utilisez le gestionnaire de paquets de votre distribution.

# Debian, Ubuntu et dérivées
sudo apt update && sudo apt install git

# Fedora, RHEL, Rocky
sudo dnf install git

# Arch
sudo pacman -S git

# Alpine
sudo apk add git

La version installée dépend de votre distribution, et l’écart est parfois important. Les versions relevées le 7 septembre 2026 sont données dans la section « Résultat mesuré » en bas de ce chapitre. Ubuntu 24.04 livre Git 2.43, sorti fin 2023 : c’est largement suffisant pour tout ce que fait ce tutoriel, puisque les commandes les plus récentes que nous utilisons datent de Git 2.23.

Se déclarer : nom et adresse e-mail

Git inscrit l’auteur de chaque commit dans l’historique. Tant que vous ne lui avez pas dit qui vous êtes, il refuse d’enregistrer quoi que ce soit :

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'root@23d1d26b6831.(none)')

Réglez donc les deux valeurs avant tout :

git config --global user.name "Damien Flandrin"
git config --global user.email "dam@example.com"

L’option --global écrit dans votre fichier personnel et vaut pour tous vos projets. Sans elle, le réglage ne concerne que le dépôt courant, ce qui est utile quand vous utilisez une adresse professionnelle sur certains projets et une adresse personnelle sur d’autres.

Utilisez une adresse que vous acceptez de rendre publique : elle apparaît dans l’historique, et l’historique est distribué à tous ceux qui clonent le projet. GitHub propose une adresse de substitution en @users.noreply.github.com si vous préférez ne pas exposer la vôtre.

Choisir le nom de la branche par défaut

C’est le point sur lequel circulent le plus d’informations fausses. On lit souvent que Git crée désormais une branche main. C’est inexact. Voici ce que produit git init avec Git 2.55, la version courante en septembre 2026 :

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>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
hint:
hint: Disable this message with "git config set advice.defaultBranchName false"
Initialized empty Git repository in /root/a1/.git/

La branche s’appelle donc bien master, et Git annonce lui-même que le défaut passera à main à partir de la version 3.0. Ce qui a changé, ce sont les hébergeurs : GitHub crée les nouveaux dépôts avec une branche main depuis octobre 2020, GitLab depuis sa version 14. D’où le décalage permanent entre ce que fait votre machine et ce que fait le serveur.

Réglez la question une fois pour toutes :

git config --global init.defaultBranch main

Le message disparaît et les dépôts créés ensuite démarrent sur main. Attention, ce réglage ne s’applique qu’aux nouveaux dépôts. Pour un dépôt qui existe déjà et dont la branche s’appelle master :

git branch -m master main

Vérifier sa configuration

Trois commandes suffisent à savoir où vous en êtes :

git config --global --list                # ce qui est réglé
git config --global --list --show-origin  # et dans quel fichier
git config --global --edit                # ouvrir le fichier

La configuration personnelle est un simple fichier texte, ~/.gitconfig, que vous pouvez lire et modifier directement :

[user]
	name = Damien Flandrin
	email = dam@example.com
[init]
	defaultBranch = main

Deux réglages supplémentaires méritent d’être posés tout de suite. L’éditeur utilisé par Git pour les messages de commit, faute de quoi vous tomberez tôt ou tard dans Vim sans savoir en sortir :

git config --global core.editor "code --wait"   # Visual Studio Code
git config --global core.editor "nano"          # ou n'importe quel éditeur de terminal

Et le comportement de git pull, que nous détaillerons au chapitre sur les branches :

git config --global pull.rebase true

S’authentifier auprès de GitHub ou GitLab

Un point de vocabulaire s’impose ici, parce qu’il fait perdre beaucoup de temps aux débutants. Votre mot de passe GitHub ne sert plus à rien pour Git. GitHub a cessé d’accepter les mots de passe de compte pour les opérations Git le 13 août 2021. Voici ce que répond le serveur si vous essayez malgré tout :

Cloning into 'depot-prive'...
remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentication failed for 'https://github.com/damienflandrin/depot-prive.git/'

Deux méthodes valides subsistent : la clé SSH ou le jeton d’accès personnel. La clé SSH demande cinq minutes de mise en place et ne se redemande plus jamais. C’est celle que nous recommandons.

Créer une clé SSH

ssh-keygen -t ed25519 -C "dam@example.com"

Validez le chemin proposé par défaut. La phrase de passe est facultative mais recommandée : elle protège la clé si votre machine est compromise.

Generating public/private ed25519 key pair.
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/id_ed25519
Your public key has been saved in /root/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:s5YjDRbNgv3/o8SvEFh4A6hzpWddSsquX0l0k4aUptw dam@example.com

Deux fichiers ont été créés. id_ed25519 est la clé privée : elle ne quitte jamais votre machine, ne se copie nulle part, ne se colle dans aucun formulaire. id_ed25519.pub est la clé publique, celle que vous confiez au serveur.

Affichez la clé publique et copiez la ligne entière :

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINjiBkboRdOPXk2UWn3UUMSv2qr8G9cGvzKsTd+ZyYCa dam@example.com

Collez-la ensuite dans Settings > SSH and GPG keys > New SSH key sur GitHub, ou dans Préférences > Clés SSH sur GitLab.

Vérifier que la clé fonctionne

ssh -T git@github.com

La première connexion vous demande de confirmer l’empreinte du serveur. Celle de GitHub pour les clés Ed25519 est SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU, comparez-la avec celle publiée par GitHub avant de répondre yes. Si tout est en ordre, GitHub vous répond par un message de bienvenue mentionnant votre nom d’utilisateur, en précisant que l’accès au shell n’est pas autorisé, ce qui est normal. Si vous obtenez à la place :

git@github.com: Permission denied (publickey).

c’est que la clé publique n’a pas été enregistrée sur votre compte, ou que vous avez collé la clé privée par erreur.

L’alternative : le jeton d’accès personnel

Si SSH est bloqué sur votre réseau, ou dans un script d’intégration continue, utilisez un jeton d’accès personnel. Sur GitHub, créez-le dans Settings > Developer settings > Personal access tokens, en privilégiant les jetons à portée fine (fine-grained) qui limitent l’accès à un dépôt précis et expirent d’eux-mêmes. Sur GitLab, l’équivalent se trouve dans Préférences > Jetons d’accès.

Le jeton s’utilise à la place du mot de passe quand Git le demande. Pour ne pas le retaper à chaque commande, activez un gestionnaire d’identifiants :

git config --global credential.helper store    # simple, mais le jeton est écrit en clair
git config --global credential.helper osxkeychain  # macOS, stockage dans le trousseau

Sous Windows, Git Credential Manager est installé et activé par défaut avec Git for Windows.

Traitez un jeton exactement comme un mot de passe : il ne se met pas dans un dépôt, pas dans un fichier de configuration versionné, pas dans une URL que vous partagez.

Votre poste est prêt. Le chapitre suivant crée un dépôt sur GitHub ou GitLab et le relie à un dossier de votre machine.

Résultat mesuré

Version de Git installée par le gestionnaire de paquets sur l’image officielle de chaque distribution, relevée le 7 septembre 2026 :

Toutes conviennent : la commande la plus récente employée dans ce tutoriel, git switch, date de Git 2.23.