Introduction

Chaque opération Git déplace des données entre trois zones : l'arborescence de travail (vos fichiers), l'index (le brouillon du prochain commit) et le dépôt (l'historique commité sous .git). Nommer ce qui se déplace où est le modèle mental le plus utile.

Introduction

Une branche de tracking distant est une ref locale qui reflète une branche sur un remote. Elles vivent sous refs/remotes/<remote>/ et sont mises à jour par git fetch (et les opérations qui impliquent un fetch, comme git pull et git clone). Vous ne commitez pas directement vers elles.

D'où elles viennent

Le refspec par défaut pour origin est :

Introduction

Normalement, HEAD pointe vers une ref de branche, qui pointe à son tour vers un commit. En HEAD détaché, HEAD pointe directement vers un commit. Le HEAD détaché n'est pas cassé ; c'est un mode délibéré utile pour inspecter l'historique et dangereux pour commiter sans réfléchir.

Introduction

Le reflog enregistre chaque changement de HEAD et de chaque pointe de branche sur votre machine locale. Il est local, par clone, et n'est pas poussé. Presque tout commit « perdu » peut être sauvé via lui.

Introduction

Git a deux résultats de merge fondamentalement différents : fast-forward, où la pointe d'une branche est simplement déplacée, et trois-voies, où un nouveau commit avec deux parents est créé. Le choix dépend de si les branches ont divergé.

Fast-forward

Si la pointe de main est un ancêtre de feature, aucun vrai merge n'est nécessaire. Git fait simplement avancer main :

Introduction

Dans Git, une branche n'est qu'une référence mobile vers un commit. Créer une branche, c'est créer un fichier de 41 octets. Comparé aux systèmes centralisés où les branches sont des copies complètes de répertoires, le modèle de Git rend le branching assez peu coûteux pour être utilisé avec désinvolture.

Introduction

L'index est un fichier binaire à .git/index qui reflète un objet tree : une liste triée de chemins avec mode, hachage et infos stat. C'est la zone de staging pour le prochain commit et un cache qui permet à Git de sauter le re-hachage des fichiers inchangés.

L'inspecter

git ls-files --stage
# 100644 a1b2c3...  0  README.md
# 100644 e4f5g6...  0  src/main.c

Stage 0 signifie « pas de conflit ». Pendant un merge, les chemins en conflit obtiennent les stages 1 (base), 2 (ours), 3 (theirs).

Introduction

Les objets sont immuables et nommés par hachage. Les références sont les noms mutables et lisibles par l'humain qui pointent vers eux. Chaque branche, tag, branche de tracking distant et HEAD est une ref.

Où vivent les refs

Les refs sont des fichiers (ou des entrées dans le fichier packed-refs) sous .git/refs/ :

Introduction

Git nomme chaque objet par le hachage cryptographique de son contenu. C'est le stockage adressé par contenu : le nom est l'empreinte du contenu. Le hachage par défaut est SHA-1 (160 bits, 40 caractères hex). Le support de SHA-256 existe expérimentalement depuis Git 2.29.

Comment un hachage est calculé

Git préfixe le contenu brut d'un en-tête de la forme <type> <size>\0, puis hache :

Introduction

Le dépôt de Git est, en son cœur, un magasin d'objets adressé par contenu. Il existe exactement quatre types d'objets : blob, tree, commit et tag. Chaque opération finit par les toucher. Comprendre ces quatre types démystifie la majeure partie de Git.

Blobs

Un blob stocke le contenu d'un fichier, rien de plus. Pas de nom de fichier, pas de permissions, pas d'historique. Deux fichiers au contenu identique partagent un seul blob, peu importe où ils vivent dans l'arbre.