Installer et configurer Git

Page 2 sur 10. Préparer le terminal, l’identité et un premier dépôt sans confondre configuration et connexion.

1. Installer et vérifier le terminal

Installez Git depuis le site officiel en choisissant les instructions de votre système. Sur Windows, Git for Windows fournit notamment Git et Git Bash. Ouvrez ensuite un nouveau terminal pour qu’il prenne en compte le chemin de l’installation.

git --version
git help

La première commande affiche la version installée ; la seconde présente l’aide générale. Si git n’est pas reconnu, vérifiez l’installation et le PATH, puis relancez le terminal. Un compte GitHub n’est pas requis pour les premières manipulations locales.

Git dispose également d’interfaces graphiques. Comprendre les commandes de base reste utile, car elles permettent d’expliquer précisément la différence entre un fichier modifié, une modification préparée et un commit partagé.

2. Configurer son identité

git config --global user.name "Votre Nom"
git config --global user.email "votre-adresse@example.com"
git config --global init.defaultBranch main
git config --show-origin --get user.name
git config --show-origin --get user.email

Le nom et le courriel sont utilisés dans les nouveaux commits. Ils ne connectent pas le terminal à GitHub et ne prouvent pas que vous possédez un compte donné. Utilisez une adresse que vous acceptez de placer dans un historique ; GitHub propose une adresse de confidentialité dans les réglages du compte.

--global configure le compte utilisateur du poste. Dans un dépôt précis, une configuration sans cette option peut définir une identité professionnelle différente. --show-origin aide à comprendre de quel fichier provient une valeur.

git config user.email "adresse-professionnelle@example.com"

Cette dernière commande s’exécute dans le dépôt concerné. Le nom de branche par défaut s’applique aux futurs dépôts créés par init ; il ne renomme pas toutes les branches déjà existantes.

3. Préparer un dossier de laboratoire

mkdir nkl-portail-lab
cd nkl-portail-lab
git init -b main
git status

Le dossier est maintenant un dépôt Git. Il contient un répertoire .git, même si votre explorateur masque les fichiers cachés. Aucun commit n’existe encore ; main est le nom prévu pour la première branche.

Évitez d’exécuter init dans un dossier parent contenant tous vos documents. Le périmètre du dépôt doit correspondre au projet. Évitez aussi de créer sans raison un dépôt Git à l’intérieur d’un autre : cela introduit des situations plus avancées, comme les dépôts imbriqués ou les sous-modules.

La racine du projet contient les fichiers de travail et le répertoire interne .git. Les commandes du laboratoire se lancent depuis cette racine.
La racine du projet contient les fichiers de travail et le répertoire interne .git. Les commandes du laboratoire se lancent depuis cette racine. Cliquer pour agrandir.

4. Créer les fichiers de départ

Set-Content -Encoding utf8 README.md "# Portail NKILItech"
Set-Content -Encoding utf8 index.html "<h1>Bienvenue chez NKILItech</h1>"
git status --short

?? signale des fichiers non suivis. Ils existent dans le dossier mais ne font pas encore partie de l’historique. README.md présente le projet ; index.html est une page volontairement minimale, suffisante pour pratiquer le versionnement.

Les éditeurs peuvent proposer un enregistrement automatique. Cette fonction ne remplace pas la sélection des changements dans Git. Fermer puis rouvrir le terminal ne crée pas non plus de commit.

5. Définir les exclusions et les conventions de texte

Set-Content -Encoding utf8 .gitignore @"
.env
.env.*
!.env.example
node_modules/
*.log
.DS_Store
"@
Set-Content -Encoding utf8 .gitattributes "* text=auto"
git check-ignore -v .env

.gitignore décrit les fichiers non suivis que Git doit ignorer. Ici, les fichiers de configuration locale, les dépendances et les journaux n’entrent pas dans les futurs commits. Le modèle .env.example reste autorisé ; il doit contenir uniquement des noms de variables et des valeurs factices.

.gitattributes permet notamment de documenter une politique de texte. La règle présentée demande à Git de détecter les fichiers textuels et de normaliser leur stockage. Une équipe peut préciser des règles LF ou CRLF selon ses outils ; il faut décider ensemble avant une normalisation massive d’un dépôt existant.

Un fichier déjà suivi ne disparaît pas de l’historique parce qu’on l’ajoute à .gitignore. Ce point sera repris dans le chapitre consacré aux erreurs et aux secrets.

6. Premier diagnostic autonome

ObservationVérificationExplication possible
git introuvablegit --version dans un nouveau terminalInstallation ou PATH incomplet
not a git repositorygit rev-parse --show-toplevelTerminal ouvert hors du projet
Identité incorrectegit config --show-origin --get user.emailValeur locale différente de la valeur globale
Fichier absent du statusgit check-ignore -v cheminMotif d’exclusion correspondant

Lire le message complet avant d’essayer une autre commande évite beaucoup d’erreurs. Conservez un terminal ouvert à la racine du laboratoire et vérifiez son emplacement avant chaque manipulation importante.

Exercices corrigés

Exercice 1 - Identité et accès

Changer user.email connecte-t-il le terminal à GitHub ?

Voir le corrigé détaillé

Non. Ce réglage renseigne les nouveaux commits. L’authentification HTTPS ou SSH et les droits sur le dépôt sont des mécanismes distincts.

Exercice 2 - Exclusion

Un fichier .env déjà suivi disparaît-il des anciens commits après ajout à .gitignore ?

Voir le corrigé détaillé

Non. L’exclusion vise les fichiers non suivis. Retirer un fichier du suivi ne nettoie pas non plus ses versions historiques. Un secret exposé doit être révoqué ou renouvelé.

Avant de passer à la suite

Mon laboratoire est initialisé, mon identité est vérifiée et les exclusions sont définies.

Pour approfondir

Sources officielles consultées pour ce chapitre : Installer Git, Configuration initiale, gitignore. Cours et schémas originaux ; exemples NKILItech pédagogiques. Vérification documentaire : 28 octobre 2026.