Premiers pas#

Introduction#

La théorie, c’est bien ; la pratique, c’est mieux. Dans ce chapitre, nous allons mettre les mains dans le cambouis en créant notre premier dépôt Git et en expérimentant le cycle de travail fondamental : modifier, indexer, valider. Chaque commande sera exécutée dans un dépôt temporaire que nous construirons pas à pas.

À la fin de ce chapitre, vous saurez créer un dépôt, suivre l’état de vos fichiers, enregistrer des modifications, examiner les différences entre versions et annuler des changements. Ces opérations constituent le quotidien de tout utilisateur de Git.

Créer un dépôt#

Définition 6 (Dépôt (repository))

Un dépôt Git est un répertoire dont l’historique complet des modifications est suivi par Git. Il contient un sous-répertoire caché .git/ qui stocke toutes les métadonnées : l’historique des commits, les branches, la configuration locale, etc. Tout le modèle objet de Git réside dans ce répertoire.

Il existe deux façons de créer un dépôt :

  • git init : initialise un nouveau dépôt vide dans le répertoire courant.

  • git clone <url> : copie un dépôt distant existant (avec tout son historique) sur votre machine.

Commençons par créer un dépôt de démonstration dans /tmp :

%%bash
cd /tmp && rm -rf demo-git && mkdir demo-git && cd demo-git && git init
Dépôt Git vide initialisé dans /tmp/demo-git/.git/

Vérifions que le répertoire .git/ a bien été créé :

%%bash
cd /tmp/demo-git
ls -la
total 0
drwxr-xr-x  3 loc  loc    60 11 mars  12:18 .
drwxrwxrwt 41 root root 1120 11 mars  12:18 ..
drwxr-xr-x  7 loc  loc   200 11 mars  12:18 .git

Le répertoire .git/ est le cœur du dépôt. Sans lui, le répertoire n’est qu’un dossier ordinaire. Configurons également l’identité pour nos commits de démonstration :

%%bash
cd /tmp/demo-git
git config user.email "demo@example.com"
git config user.name "Demo User"

Remarque 4

git init crée un dépôt local, entièrement autonome. Aucune connexion réseau n’est nécessaire. À l’inverse, git clone copie un dépôt distant (par exemple hébergé sur GitHub ou GitLab) en téléchargeant tout son historique. Après un clone, vous disposez d’une copie complète et indépendante du projet.

Le cycle de travail#

Définition 7 (Cycle de travail Git)

Le cycle de travail fondamental de Git se décompose en trois étapes :

  1. Modifier (edit) : vous travaillez normalement sur vos fichiers dans le répertoire de travail.

  2. Indexer (stage) : vous sélectionnez les modifications à inclure dans le prochain commit avec git add.

  3. Valider (commit) : vous enregistrez un instantané permanent de l’état indexé avec git commit.

Ce cycle se répète indéfiniment tout au long de la vie du projet.

Mettons cela en pratique. Créons un premier fichier :

%%bash
cd /tmp/demo-git
echo "Hello Git" > readme.txt

Interrogeons Git sur l’état du dépôt :

%%bash
cd /tmp/demo-git
git status
Sur la branche main

Aucun commit

Fichiers non suivis:
  (utilisez "git add <fichier>..." pour incl
ure dans ce qui sera validé)
	readme.txt

aucune modification ajoutée à la validation mais des fi
chiers non suivis sont présents (utilisez "git add" pour les suivre)

Le fichier apparaît comme Untracked : Git le voit, mais ne le suit pas encore. Indexons-le avec git add :

%%bash
cd /tmp/demo-git
git add readme.txt
git status
Sur la branche main

Aucun commit

Modifications qui seront validées :
  (utilisez "git rm --cached
 <fichier>..." pour désindexer)
	nouveau fichier : readme.txt

Le fichier est maintenant dans la zone d’indexation (staging area), prêt à être validé. Créons notre premier commit :

%%bash
cd /tmp/demo-git
git commit -m "Initial commit"
[main (commit racine) c73c7f8] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 re
adme.txt

Vérifions que le répertoire de travail est propre :

%%bash
cd /tmp/demo-git
git status
Sur la branche main
rien à valider, la copie de travail est propre

Le message nothing to commit, working tree clean confirme que toutes les modifications ont été enregistrées.

Diagramme du cycle de vie des fichiers#

La visualisation suivante montre les différents états possibles d’un fichier dans Git et les commandes qui permettent de passer d’un état à l’autre.

Hide code cell source

import matplotlib.pyplot as plt
import matplotlib.patches as mpatches

fig, ax = plt.subplots(1, 1, figsize=(12, 4))

# Define states and positions
states = {
    'Untracked':   (0.5, 0.5),
    'Staged':      (3.5, 0.5),
    'Committed':   (6.5, 0.5),
    'Modified':    (9.5, 0.5),
}

colors = {
    'Untracked': '#e74c3c',
    'Staged':    '#f39c12',
    'Committed': '#2ecc71',
    'Modified':  '#3498db',
}

# Draw state boxes
for state, (x, y) in states.items():
    box = mpatches.FancyBboxPatch(
        (x - 0.9, y - 0.25), 1.8, 0.5,
        boxstyle="round,pad=0.1",
        facecolor=colors[state], edgecolor='black', linewidth=1.5, alpha=0.85
    )
    ax.add_patch(box)
    ax.text(x, y, state, ha='center', va='center',
            fontsize=11, fontweight='bold', color='white')

# Define transitions: (start, end, label, curvature)
transitions = [
    ('Untracked',  'Staged',    'git add',         0.0),
    ('Staged',     'Committed', 'git commit',      0.0),
    ('Committed',  'Modified',  'edit',             0.0),
    ('Modified',   'Staged',    'git add',         -0.45),
]

for start, end, label, curve in transitions:
    x0, y0 = states[start]
    x1, y1 = states[end]

    if start == 'Modified' and end == 'Staged':
        # Curved arrow going below
        ax.annotate(
            '', xy=(x1 + 0.9, y1 - 0.25), xytext=(x0 - 0.9, y0 - 0.25),
            arrowprops=dict(
                arrowstyle='->', color='#2c3e50', lw=2,
                connectionstyle=f'arc3,rad={curve}'
            )
        )
        ax.text((x0 + x1) / 2, -0.35, label,
                ha='center', va='center', fontsize=9,
                fontstyle='italic', color='#2c3e50',
                bbox=dict(boxstyle='round,pad=0.2', facecolor='white',
                          edgecolor='#bdc3c7', alpha=0.9))
    else:
        ax.annotate(
            '', xy=(x1 - 0.9, y1), xytext=(x0 + 0.9, y0),
            arrowprops=dict(arrowstyle='->', color='#2c3e50', lw=2)
        )
        mid_x = (x0 + x1) / 2
        ax.text(mid_x, y0 + 0.35, label,
                ha='center', va='center', fontsize=9,
                fontstyle='italic', color='#2c3e50',
                bbox=dict(boxstyle='round,pad=0.2', facecolor='white',
                          edgecolor='#bdc3c7', alpha=0.9))

ax.set_xlim(-1, 11)
ax.set_ylim(-0.7, 1.1)
ax.set_aspect('equal')
ax.axis('off')
ax.set_title("Cycle de vie d'un fichier dans Git", fontsize=13, fontweight='bold', pad=15)

plt.show()
_images/f99b1a4c6d2d161202327f99e3ad7abb90d7f65913f9c3a900dd334189286314.png

Exemple 3

Pour résumer le cycle de travail minimal :

  1. Vous créez ou modifiez un fichier dans votre répertoire de travail.

  2. Vous lancez git add <fichier> pour indexer les modifications.

  3. Vous lancez git commit -m "message" pour enregistrer un instantané.

Ces trois étapes constituent le rythme fondamental de Git. Chaque commit est un point de sauvegarde vers lequel on peut revenir à tout moment.

Examiner les changements#

Avant de valider des modifications, il est essentiel de vérifier exactement ce qui a changé. La commande git diff répond à cette question.

Modifions notre fichier :

%%bash
cd /tmp/demo-git
echo "Bienvenue dans le monde de Git." >> readme.txt
echo "Ce fichier sert de démonstration." >> readme.txt

Examinons les différences entre le répertoire de travail et la zone d’indexation :

%%bash
cd /tmp/demo-git
git diff
diff --git a/readme.txt b/readme.txt
index 9f4d96d..ec4f383 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1,3 @@
 Hello Git
+Bienvenue dans le monde de Git.
+Ce fichier sert de démonstration.

Les lignes précédées de + sont les ajouts. Indexons maintenant ces modifications et comparons la zone d’indexation avec le dernier commit :

%%bash
cd /tmp/demo-git
git add readme.txt
git diff --staged
diff --git a/readme.txt b/readme.txt
index 9f4d96d..ec4f383 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1,3 @@
 Hello Git
+Bienvenue dans le monde de Git.
+Ce fichier sert de démonstration.

Remarque 5

git diff (sans option) compare le répertoire de travail à la zone d’indexation : il montre les modifications que vous n’avez pas encore indexées. git diff --staged compare la zone d’indexation au dernier commit : il montre exactement ce qui sera inclus dans le prochain git commit. Si vous avez indexé toutes vos modifications, git diff sera vide et seul git diff --staged montrera quelque chose.

Validons cette modification :

%%bash
cd /tmp/demo-git
git commit -m "Ajout de contenu au readme"
[main 71c310c] Ajout de contenu au readme
 1 file changed, 2 insertions(+)

Lire l’historique#

Ajoutons quelques commits supplémentaires pour avoir un historique intéressant à explorer :

%%bash
cd /tmp/demo-git
echo "# Projet de démonstration" > projet.txt
echo "Version 1.0" >> projet.txt
git add projet.txt
git commit -m "Ajout du fichier projet"

echo "## Description" >> projet.txt
echo "Ce projet illustre les commandes Git de base." >> projet.txt
git add projet.txt
git commit -m "Ajout de la description du projet"

echo "notes.txt" > .gitignore
git add .gitignore
git commit -m "Ajout du fichier .gitignore"
[main b4be118] Ajout du fichier projet
 1 file changed, 2 insertions(+)
 create mode 100644 projet.t
xt
[main e889ef3] Ajout de la description du projet
 1 file changed, 2 insertions(+)
[main 652a96f] Ajout du fichier .gitignore
 1 file changed, 1 insertion(+)
 create mode 100644 .giti
gnore

Définition 8 (Commit)

Un commit Git est un instantané (snapshot) de l’état complet du projet à un instant donné. Chaque commit contient :

  • un arbre (tree) : la structure complète des fichiers et répertoires à cet instant.

  • un message : une description textuelle des modifications apportées.

  • un auteur et une date : qui a créé le commit et quand.

  • un pointeur vers le(s) parent(s) : le commit précédent (ou les deux parents dans le cas d’une fusion).

  • un identifiant SHA-1 : une empreinte cryptographique unique de 40 caractères hexadécimaux.

Les commits forment ainsi un graphe orienté acyclique (DAG), où chaque nœud pointe vers son parent.

La commande git log affiche l’historique des commits du plus récent au plus ancien :

%%bash
cd /tmp/demo-git
git log
commit 652a96f2cadbec03695f6b78ef2f7f6760c751e7
Author: Demo User <demo@example.com>
Date:   Wed Mar
 11 12:18:34 2026 +0100

    Ajout du fichier .gitignore
commit e889ef3ce872c99e0b7d2266ca62f7b78e946e8a
Author: Demo User <demo@example.com>
Date:   Wed Ma
r 11 12:18:33 2026 +0100

    Ajout de la description du projet
commit b4be118e7b7d8f304273f9a5e0be10f19f1d6c23
Author: Demo User <demo@example.com>
Date:   Wed Ma
r 11 12:18:33 2026 +0100

    Ajout du fichier projet

commit 71c310c4f126a009514f76b8d7233704e13cc8
a4
Author: Demo User <demo@example.com>
Date:   Wed Mar 11 12:18:33 2026 +0100

    Ajout de contenu
 au readme

commit c73c7f82da77fd27e608d98c88830ebca8f12d93
Author: Demo User <demo@example.com>
Dat
e:   Wed Mar 11 12:18:26 2026 +0100

    Initial commit

Le format par défaut est verbeux. L’option --oneline offre une vue compacte :

%%bash
cd /tmp/demo-git
git log --oneline
652a96f Ajout du fichier .gitignore
e889ef3 Ajout de la description du projet
b4be118 Ajout du fichier projet
71c310c Ajout de contenu a
u readme
c73c7f8 Initial commit

Pour les projets avec des branches (que nous verrons dans un prochain chapitre), l’option --graph dessine le graphe des commits :

%%bash
cd /tmp/demo-git
git log --oneline --graph
* 652a96f Ajout du fichier .gitignore
* e889ef3 Ajout de la description du projet
* b4be118 Ajout du
 fichier projet
* 71c310c Ajout de contenu au readme
* c73c7f8 Initial commit

Remarque 6

Chaque commit est identifié par un hash SHA-1 unique (par exemple a3f4b2c). Ce hash est calculé à partir du contenu du commit, de ses métadonnées et de son parent. Deux commits ayant le même contenu mais un parent différent auront des hashs différents. En pratique, les 7 premiers caractères suffisent à identifier un commit de façon non ambiguë dans la plupart des projets.

Annuler des modifications#

Il arrive souvent de vouloir revenir en arrière. Git offre des commandes pour annuler les modifications à différents niveaux.

Annuler des modifications non indexées#

Supposons que vous modifiez un fichier, puis changez d’avis :

%%bash
cd /tmp/demo-git
echo "Cette ligne est une erreur." >> readme.txt
cat readme.txt
Hello Git
Bienvenue dans le monde de Git.
Ce fichier sert de démonstration.
Cette ligne est une err
eur.
%%bash
cd /tmp/demo-git
git diff
diff --git a/readme.txt b/readme.txt
index ec4f383..5d164e2 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,3 +1,4 @@
 Hello Git
 Bienvenue dans le monde de Git.
 Ce fichier sert de démonstration.
+Ce
tte ligne est une erreur.

Pour restaurer le fichier à son état dans le dernier commit :

%%bash
cd /tmp/demo-git
git restore readme.txt
cat readme.txt
Hello Git
Bienvenue dans le monde de Git.
Ce fichier sert de démonstration.

Le fichier a retrouvé son contenu précédent. La ligne erronée a disparu.

Désindexer un fichier#

Si vous avez indexé une modification par erreur, vous pouvez la retirer de la zone d’indexation sans perdre la modification dans le répertoire de travail :

%%bash
cd /tmp/demo-git
echo "Modification expérimentale." >> readme.txt
git add readme.txt
git status
Sur la branche main
Modifications qui seront validées :
  (utilisez "git restore --staged <fichier>
..." pour désindexer)
	modifié :         readme.txt
%%bash
cd /tmp/demo-git
git restore --staged readme.txt
git status
Sur la branche main
Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." p
our mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modi
fications dans le répertoire de travail)
	modifié :         readme.txt

aucune modification n'a 
été ajoutée à la validation (utilisez "git add" ou "git commit -a")

Le fichier est de retour à l’état Modified (non indexé), mais la modification est toujours présente dans le répertoire de travail. Nettoyons pour terminer :

%%bash
cd /tmp/demo-git
git restore readme.txt

Remarque 7

Les commandes git restore et git restore --staged ont remplacé les anciennes syntaxes git checkout -- <fichier> et git reset HEAD <fichier>, jugées confuses car checkout et reset servaient à trop de choses différentes. Depuis Git 2.23 (2019), git restore est la manière recommandée d’annuler des modifications dans le répertoire de travail ou la zone d’indexation.

Résumé#

Ce chapitre a couvert les commandes fondamentales du cycle de travail quotidien avec Git. Le tableau suivant récapitule chaque commande et son rôle :

Commande

Description

git init

Initialiser un nouveau dépôt dans le répertoire courant

git clone <url>

Copier un dépôt distant avec tout son historique

git status

Afficher l’état des fichiers (modifiés, indexés, non suivis)

git add <fichier>

Indexer des modifications pour le prochain commit

git commit -m "msg"

Enregistrer un instantané des modifications indexées

git diff

Voir les modifications non indexées (travail vs index)

git diff --staged

Voir les modifications indexées (index vs dernier commit)

git log

Afficher l’historique des commits

git log --oneline

Afficher l’historique en format compact

git restore <fichier>

Annuler les modifications dans le répertoire de travail

git restore --staged <fichier>

Retirer un fichier de la zone d’indexation

Remarque 8

Ces commandes suffisent pour travailler efficacement en solo sur un projet. Dans les prochains chapitres, nous explorerons le modèle objet interne de Git, puis les branches, qui permettent de travailler sur plusieurs lignes de développement en parallèle.