Niveau : Débutant

Chapitre 1 : Les notions essentielles

Concepts clés abordés

• Configuration (git config, .gitignore)
• Zones de Git (working copy, stage, local repository, remote)
• Références (hash, HEAD, branche, tag, remote references)
• Commandes essentielles (init, clone, status, log, show, add, commit, checkout, switch, branch, push, pull)
• Workflow classique de travail

Configuration

La configuration de Git se fait via la commande git config. Les paramètres essentiels sont le nom et l'email, qui identifient l'auteur des commits. La configuration peut être globale (pour tous les projets) ou locale (spécifique à un dépôt).

Pour configurer votre nom et votre email de manière globale (recommandé pour un usage personnel) :

git config --global user.name "Votre Nom"  
git config --global user.email "votre.email@example.com"

Pour configurer votre nom et votre email de manière locale (spécifique à un dépôt) :

git config user.name "Votre Nom"  
git config user.email "votre.email@example.com"

La configuration locale écrase la configuration globale pour le dépôt concerné. Utilisez git config --list pour voir toutes les configurations actives, ou git config user.name et git config user.email pour vérifier les valeurs actuelles.

Le fichier .gitignore permet d'exclure des fichiers et répertoires du suivi Git. C'est essentiel pour éviter de versionner des fichiers générés, des dépendances, des fichiers de configuration locaux ou des secrets.

Les zones de git

Git organise les fichiers en quatre zones distinctes :

• Working copy : répertoire de travail où vous modifiez les fichiers, le file system que vous voyez dans votre IDE
• Stage (ou index) : zone intermédiaire où les fichiers sont préparés avant le commit. Pour un fichier donné, le contenu de la working copy peut être différent du contenu du stage en fonction des actions que vous avez réalisé (cf.: git add)
• Local repository : historique local des commits sur votre machine
• Remote repository copy : copie locale du dépôt distant servant de première référence pour les intéractions avec l'historique "publié".
• Remote repository : dépôt distant partagé avec l'équipe (GitHub, GitLab, etc.). Le partage des historiques locaux se fait par synchronisation de chaque développeur avec le remote de référence

Le flux classique consiste à modifier des fichiers dans le working copy, les ajouter au stage avec git add, puis les commiter dans le repository local avec git commit.

Les références

Chaque commit est identifié par un Hash (SHA-1) unique de 40 caractères. Il est calculé à partir du contenu du commit et garantit l'intégrité des données.

Pour gérer et manipuler l'historique, Git utilise des références vers les commits identifiés grâce au hash. Ces références sont le points d'entrée de l'historique, vous pouvez les voir comme des pointeurs vers un commit :

• HEAD : pointeur vers le commit actuel sur lequel vous travaillez. Cette référence se déplace après chaque commande, elle représente votre navigation dans l'historique.
• Branche : pointeur mobile qui suit une ligne de développement. La branche par défaut est généralement main ou master. Attention aux'abus de langage : au quotidien une branche représente l'ensemble des commits d'une ligne de travail, mais en réalité une branche n'est qu'une référence vers le dernier commit de cette ligne.
• Tag : référence fixe pointant vers un commit spécifique, souvent utilisé pour marquer des versions (ex: v1.0.0).
• Remote references : références aux branches et tags du dépôt distant (préfixées par origin/ par défaut).

Les commandes essentielles

Initialisation d'un projet

git init crée un nouveau dépôt Git dans le répertoire courant. Elle initialise le répertoire .git qui contient toute la structure interne de Git (historique, références, configuration). Cette commande ne doit être utilisée qu'une fois par projet, à la création. Si vous avez récupéré un projet existant ayant déjà un historique, alors cette commande ne doit plus être utilisée.

git clone crée une copie locale d'un dépôt distant, incluant tout l'historique et les branches. Cette commande ne doit être utilisée qu'une seule fois par projet à copier. Une fois récupéré en local, cette commande ne doit plus être utilisée.

État de l'historique

git status affiche l'état actuel du working copy et du stage, indiquant quels fichiers sont modifiés, ajoutés ou non suivis.

git log affiche l'historique des commits. De nombreuses options permettent de personnaliser l'affichage (format, nombre de commits, filtrage par auteur, date, etc.).

Une manière efficace de visualiser l'historique complet avec toutes les branches est d'utiliser git log --all --graph --oneline. Cette commande affiche un graphe ASCII de toutes les branches (--all), montre les relations entre les commits (--graph), et présente chaque commit sur une seule ligne avec son hash court et son message (--oneline), offrant une vue d'ensemble claire de la structure de l'historique.

git show affiche les détails d'un commit spécifique : message, auteur, date et modifications apportées.

Manipulation de l'historique

git add ajoute des fichiers au stage. Vous pouvez ajouter des fichiers spécifiques ou utiliser git add . pour tout ajouter.

git commit crée un nouveau commit à partir des fichiers présents dans le stage. Le message de commit doit être clair et descriptif. L'option -m permet de spécifier le message directement en ligne de commande : git commit -m "Message du commit", évitant ainsi l'ouverture d'un éditeur. Pour un message plus long, vous pouvez utiliser plusieurs -m : git commit -m "Titre" -m "Description détaillée".

git checkout permet de se déplacer entre les commits, branches ou tags. Cette commande modifie le working copy pour correspondre à l'état du commit ciblé.

git switch est une commande plus récente et intuitive pour changer de branche, remplaçant git checkout dans ce cas d'usage.

git branch permet de créer, lister, renommer ou supprimer des branches.

Interaction avec le remote

git push envoie les commits locaux vers le dépôt distant. Par défaut, il pousse la branche courante vers la branche correspondante sur origin.

git pull récupère les modifications du dépôt distant et les fusionne dans la branche courante. C'est équivalent à git fetch suivi de git merge.

Le workflow classique de travail

Le workflow standard pour travailler sur une nouvelle fonctionnalité suit ces étapes :

1. Se positionner sur la branche principale : git switch main
2. Récupérer les dernières modifications : git pull
3. Créer une nouvelle branche de travail : git checkout -b feature/nom-fonctionnalite
4. Effectuer les modifications dans le code
5. Ajouter les fichiers modifiés : git add .
6. Créer un commit : git commit -m "Description des modifications"
7. Envoyer la branche sur le remote : git push -u origin feature/nom-fonctionnalite, une fois le premier push de votre branche effectué, vous pourrez vous contenter de git push

Une fois le travail terminé, une pull request (ou merge request) devra être créée pour demander l'intégration de la branche dans la branche principale.

Questions clés (validation des acquis du chapitre)

• Zones Git : quelle est la différence entre working copy, stage et local repository ? À quel moment un fichier "existe" dans chacune de ces zones ?
• Stage : dans quel cas le contenu d'un fichier en stage peut-il être différent de celui dans la working copy ? Comment le vérifier ?
• .gitignore : que se passe-t-il si vous ajoutez un fichier au suivi puis vous ajoutez ensuite au .gitignore ?
• Références : qu'est-ce que HEAD ? En quoi une branche est-elle "juste un pointeur" ?
• Inspection : quand utiliser git show plutôt que git log ?
• Lecture d'historique : que vous apporte git log --all --graph --oneline par rapport à un git log simple ?
• Commit : pourquoi viser des commits atomiques ?
• Workflow : pourquoi commencer par git switch main puis git pull avant de créer une branche ?
• Remote : à quoi sert -u lors du premier git push -u origin feature/... ?

Exercices :

Exercice 1 — Initialiser un environnement Git propre

Objectif : configurer l'identité Git et comprendre la portée global vs local.
Étapes :

• Configurer votre identité globale : git config --global user.name "Votre Nom" puis git config --global user.email "vous@exemple.com".
• Créer un dépôt bac à sable (dossier vide) puis vérifier l'identité effective avec git config user.name / git config user.email.
• Surcharger localement (dans le dépôt) avec git config user.email "vous+projet@exemple.com" puis constater la différence via git config --list --show-origin.

Exercice 2 — Cycle de base : working copy → stage → commit

Objectif : manipuler les zones (working copy/stage/repository) et lire l'historique.
Étapes :

• Créer 2 fichiers (ex : README.md, notes.txt) et un .gitignore qui ignore un fichier temporaire (ex : tmp.log).
• Observer git status avant/après git add, puis faire un commit (git commit -m "Init projet").
• Vérifier l'historique avec git log --all --graph --oneline et inspecter le commit avec git show.

Exercice 3 — Branches et workflow de feature

Objectif : reproduire un workflow de travail simple et lisible.
Étapes :

• Créer une branche feature/…, faire 1 à 3 commits atomiques.
• Revenir sur main, faire 1 à 3 commits atomiques.
• Relire l'historique avec git log --all --graph --oneline et constater la divergence.