Quatre types d'objets

Git stocke tout sous forme d'objets adressés par contenu sous .git/objects. Il y a quatre types : blob (contenu de fichier), tree (listing de répertoire de blobs et subtrees), commit (pointeur d'instantané avec auteur, committer, message et parents), et tag (tag annoté avec signataire et message). Chacun est nommé par le SHA-1 (ou SHA-256) de son contenu.

Le problème que résolvent les worktrees

Vous êtes en pleine feature quand une demande urgente de hotfix arrive. Faire un stash ou changer de contexte est risqué et lent. Les worktrees vous permettent de faire checkout de branches additionnelles dans des répertoires séparés, partageant tous une seule base de données d'objets sous-jacente. Chaque worktree a son propre HEAD, index et arbre de travail.

Le cas de la signature SSH

GPG est puissant mais opérationnellement pénible. Depuis Git 2.34, vous pouvez signer commits et tags avec les clés SSH que vous utilisez déjà pour push. Pas de keyring, pas de jonglerie de passphrase, pas de réseau de confiance séparé. GitHub, GitLab, Gitea et Forgejo acceptent tous les commits signés SSH.

Pourquoi signer

Un commit signé atteste cryptographiquement que "ce commit a été créé par le détenteur de cette clé, sans changement depuis la signature." Les signatures défendent contre l'usurpation et l'altération, et des plateformes comme GitHub affichent un badge "Verified" quand la signature correspond à une clé configurée.

Ce que fait gitattributes

.gitattributes applique des paramètres par chemin : fins de ligne, drivers de diff et merge, filtres d'export, déclarations d'encodage. Contrairement à .gitignore, les attributes s'appliquent aux fichiers suivis et sont honorés par toute l'équipe.

Fins de ligne

# .gitattributes
* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

core.autocrlf vs gitattributes

core.autocrlf est un fallback par développeur. Gitattributes fait autorité et est partagé.

Pourquoi des diffs personnalisés

Le diff par défaut de Git est ligne par ligne en texte. Pour les formats binaires (PDF, DOCX, images) et le texte structuré où les diffs par ligne ne sont pas utiles (JS minifié, dumps SQL générés), les drivers de diff personnalisés produisent quelque chose que les humains peuvent lire.

Stratégies vs drivers

Une stratégie de merge décide comment Git combine deux histoires — ort (par défaut depuis Git 2.34), recursive, resolve, octopus et ours. Un driver de merge est une logique par fichier qui s'exécute quand les deux côtés ont changé le même fichier.

Après coup

Là où les hooks de temps de commit donnent forme aux commits, les hooks de cette page y réagissent. post-commit s'exécute localement après chaque commit, pre-push avant de transférer les objets vers un remote, et post-receive sur le serveur après l'arrivée d'un push.

Hooks côté client

Les hooks sont des scripts exécutables dans .git/hooks/ (ou là où pointe core.hooksPath). Git les invoque à des moments bien définis.

Ce que fait rerere

Rerere — "reuse recorded resolution" — observe comment vous résolvez un conflit de merge, enregistre la résolution et la rejoue la prochaine fois que le même conflit apparaît. Inestimable sur les branches de longue durée qui rebasent ou mergent à répétition contre un main actif.