Préparer Git côté local : démarrer dans de bonnes conditions

Avant de taper notre première commande Git, encore faut-il que notre poste soit prêt. Cet article prolonge Démystifier Git : à quoi ça sert vraiment ?, en nous guidant pas à pas dans l’installation de Git, la vérification de son bon fonctionnement, et l’intégration dans un éditeur comme VS Code. Nous n’entrons pas encore dans la gestion des versions : l’objectif est simplement de poser un environnement propre, stable, et compréhensible. Un terminal qui répond, un nom bien configuré, et un éditeur qui suit le rythme… c’est déjà beaucoup pour partir du bon pied.

Installer Git selon notre système

Git peut être installé sur Windows, macOS ou Linux, mais chaque système a ses spécificités. Pour éviter les mauvaises surprises, prenons le temps de choisir la bonne méthode.

Sur Windows, nous téléchargeons l’installeur depuis git-scm.com et nous lançons l’installation. Plusieurs options s’affichent : il est conseillé de garder Git Bash, utile pour exécuter les commandes dans un terminal, et de laisser les options par défaut sauf si nous savons ce que nous faisons. Une attention particulière à l’étape « Configuring line ending conversions » (conversion des fins de ligne) peut éviter des conflits futurs entre Windows et les systèmes UNIX.

Sur macOS, Git est souvent déjà présent. Un simple git --version dans le terminal nous le dira. Si ce n’est pas le cas, une fenêtre nous proposera d’installer les outils de développement Apple, ce qui suffira. Sinon, nous pouvons passer par Homebrew avec la commande :

brew install git

Sur Linux, l’installation passe par le gestionnaire de paquets. Sur Debian/Ubuntu, par exemple :

sudo apt install git

Une fois Git installé, ouvrons un terminal (ou Git Bash sous Windows) et tapons :

git --version

## Git répond normalement quelque chose comme :
git version 2.44.0.windows.1

Ce retour confirme que Git est bien en place. Si la commande n’est pas reconnue, c’est que le chemin d’accès n’a pas été configuré correctement. Dans ce cas, mieux vaut relancer l’installation ou vérifier les variables système.

Mieux vaut une version à jour qu’un bug ancien

Si Git est déjà installé sur notre poste, il est utile de vérifier si une version plus récente est disponible. Cela garantit la compatibilité avec les fonctionnalités modernes et les dépôts distants.

git --version

Si cette version est inférieure à celle annoncée sur le site officiel, mieux vaut effectuer la mise à jour avant d’aller plus loin.

Sur Windows, nous pouvons relancer l’installeur depuis git-scm.com, mais il est aussi possible d’utiliser cette commande dans Git Bash pour déclencher une mise à jour directe :

git update-git-for-windows

Sur macOS avec Homebrew, une simple commande suffit :

brew upgrade git

Sur Linux, la mise à jour passe généralement par le gestionnaire de paquets. Sous Debian ou Ubuntu, nous pouvons lancer :

sudo apt update
sudo apt install git

Cela permet de récupérer la dernière version disponible dans les dépôts officiels. Si nous avons besoin d’une version plus récente que celle fournie par défaut, il faudra envisager d’ajouter un dépôt tiers ou de compiler Git manuellement, mais ce n’est pas indispensable pour démarrer sereinement.

Définir qui nous sommes pour Git

Avant de créer notre premier projet, Git a besoin de savoir qui signe les modifications. C’est un peu comme inscrire notre nom sur un cahier partagé. Nous configurons donc une identité globale avec deux commandes simples :

git config --global user.name "Votre Prénom Nom"
git config --global user.email "votre@email.com"

Ces informations seront automatiquement associées à chaque commit. Pour vérifier que tout est bien enregistré, nous pouvons demander à Git de nous afficher sa configuration :

git config --list

## Voici une simulation réaliste de ce que Git peut afficher après une configuration simple avec git config --list 
user.name=Birnou Sdarte
user.email=birnou@example.com
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.autocrlf=true
credential.helper=manager-core

Cette sortie nous montre que Git a bien pris en compte notre nom et notre email, ainsi que d’autres réglages par défaut, comme le format du dépôt ou la gestion des fins de ligne. Seules les deux premières lignes sont liées à notre identité, le reste concerne le comportement général de Git.

Connecter Git à notre éditeur de code

Git peut s’utiliser uniquement en ligne de commande, mais nous gagnons en clarté et en confort en le connectant à notre éditeur. Avec Visual Studio Code, cette intégration est fluide, immédiate, et souvent déjà active sans rien faire. Dans Visual Studio Code, l’onglet « Source Control » est visible par défaut sur le côté gauche, avec une icône en forme de branche. Si jamais il n’apparaît pas, nous pouvons :

1. Ouvrir la palette de commandes (Ctrl + Shift + P ou ⌘ + Shift + P),
2. Taper View: Toggle Source Control,
3. Ou cliquer sur le menu Affichage > Contrôle de code source.

Dès qu’un projet est initialisé avec Git (git init), cet onglet devient actif. Il affiche alors les fichiers modifiés, propose des actions de commit, et nous aide à suivre l’évolution du code sans quitter l’éditeur.

Pour aller plus loin, nous pouvons installer GitLens, une extension gratuite qui ajoute de nombreuses informations utiles : qui a modifié chaque ligne, quand, et pourquoi. Elle enrichit notre lecture du code sans rien alourdir.

Autre extension précieuse : Git Graph, qui affiche visuellement les branches et l’historique des versions. Cela rend la navigation bien plus intuitive, surtout quand plusieurs personnes travaillent sur un même projet.

Ces outils ne remplacent pas la ligne de commande, mais ils nous accompagnent efficacement au quotidien. Nous gardons ainsi le contrôle, sans perdre de vue la logique de Git.

Et si nous utilisons encore Dreamweaver ?

Git et Dreamweaver ne font pas bon ménage. Même si Dreamweaver affiche parfois les fichiers modifiés, il ne sait pas gérer les branches, les conflits, ou l’historique de manière fiable. Le dossier .git, essentiel au suivi du projet, est souvent ignoré ou mal interprété.

En pratique, cela signifie que nous risquons de perdre des changements ou de ne pas comprendre ce que Git a réellement fait. Pour éviter toute confusion, mieux vaut utiliser Git en dehors de Dreamweaver : avec Git Bash, VS Code, ou un outil graphique dédié. Nous pouvons toujours revenir dans Dreamweaver pour éditer les fichiers, mais jamais pour piloter Git.

Tout est prêt, mais nous n’avons encore rien versionné

Nous avons installé Git, vérifié qu’il fonctionne, configuré notre identité, et connecté notre éditeur. Pourtant, aucun fichier n’est encore suivi, aucun projet n’est versionné. C’est normal : cette étape de préparation nous évite bien des erreurs dès que nous initierons notre premier dépôt. Dans le prochain article, nous verrons comment créer un projet Git, faire nos premiers commits, gérer l’évolution du code, et poser les bases d’un historique propre.