Git Contrôle de Version : La Référence Technique Complète pour les Développeurs

Git est un système de contrôle de version distribué (DVCS) qui enregistre des instantanés de l’arborescence de fichiers d’un projet au fil du temps, permettant à un nombre illimité de contributeurs de travailler en parallèle sans écraser les modifications des autres. Chaque développeur dispose d’une copie complète du dépôt — y compris l’intégralité de l’historique des commits — sur sa machine locale, éliminant tout point de défaillance unique et permettant des flux de travail entièrement hors ligne.

Créé par Linus Torvalds en avril 2005 pour remplacer BitKeeper dans le développement du noyau Linux, Git a été conçu à partir de principes fondamentaux autour de trois exigences non négociables : la vitesse, l’intégrité des données et la prise en charge des flux de travail non linéaires et distribués. Ces objectifs de conception définissent encore aujourd’hui ce qui rend Git fondamentalement différent de ses prédécesseurs et pourquoi il reste le VCS dominant plus de deux décennies plus tard.

En quoi Git diffère du contrôle de version centralisé

Comprendre l’architecture de Git nécessite une comparaison directe avec les systèmes centralisés comme Subversion (SVN) ou CVS, où un seul serveur faisant autorité héberge le dépôt canonique et les développeurs extraient des copies de travail superficielles.

Le modèle distribué signifie que même si une plateforme d’hébergement comme GitHub subit une panne, le clone local de chaque développeur constitue une sauvegarde complète et faisant autorité de l’intégralité de l’historique du projet.

Architecture centrale : ce que Git stocke réellement

Git ne stocke pas des diffs. Il stocke des instantanés. Chaque commit pointe vers un objet arbre représentant l’état complet de chaque fichier suivi à ce moment-là. Si un fichier n’a pas changé entre deux commits, Git stocke un pointeur vers le blob précédent plutôt que de le dupliquer — c’est ainsi que Git atteint à la fois la complétude et l’efficacité de stockage.

Les quatre types d’objets fondamentaux dans le magasin d’objets de Git (.git/objects/) sont :

• Blob — contenu brut du fichier, adressé par hachage SHA
• Tree — une liste de répertoire associant les noms de fichiers aux hachages de blob ou de sous-arbre
• Commit — un pointeur vers un arbre, zéro ou plusieurs commits parents, des métadonnées d’auteur et un message
• Tag — un pointeur annoté vers un commit spécifique, utilisé pour les marqueurs de version

Chaque objet est immuable et adressé par contenu. La modification d’un seul octet dans un fichier produit un hachage SHA complètement différent, qui se propage à travers les objets arbre et commit. C’est pourquoi l’historique de Git est cryptographiquement infalsifiable — vous ne pouvez pas modifier silencieusement un commit passé sans changer tous les hachages de commits suivants.

La zone de staging (également appelée index, stockée dans .git/index) est un fichier binaire qui contient le prochain commit proposé. Ce modèle à trois zones — répertoire de travail, index, dépôt — est la fonctionnalité architecturale de Git la plus mal comprise et la source de la plupart des confusions pour les débutants.

Installation et configuration de Git

Avant d’exécuter des commandes, vérifiez votre installation et configurez votre identité. Git intègre les informations sur l’auteur dans chaque objet commit, et une identité mal configurée est l’une des causes les plus fréquentes d’historiques de commits désordonnés sur les dépôts partagés.

# Verify installation
git --version

# Set global identity (stored in ~/.gitconfig)
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Set default branch name to 'main' (modern convention)
git config --global init.defaultBranch main

# Set preferred editor for commit messages
git config --global core.editor "vim"

# Enable colored output
git config --global color.ui auto

# Verify configuration
git config --list

La configuration est en couches : --system (tous les utilisateurs, /etc/gitconfig), --global (utilisateur actuel, ~/.gitconfig) et --local (dépôt, .git/config). Les portées plus spécifiques remplacent les plus générales.

Commandes Git essentielles : référence complète

Initialisation et clonage

git init crée un nouveau dépôt en écrivant un répertoire .git/ dans le dossier courant. Il ne crée aucun commit — le dépôt commence vide.

git init
git init my-project        # Initialize into a new subdirectory
git init --bare repo.git   # Bare repository (no working tree, used for servers)

Un dépôt nu contient uniquement le magasin d’objets et les refs — pas de répertoire de travail. C’est le format correct pour un dépôt distant vers lequel plusieurs développeurs poussent. Si vous hébergez vous-même Git sur un serveur VPS Hosting, initialisez toujours les dépôts partagés en tant que dépôts nus.

git clone crée une copie locale complète d’un dépôt distant, incluant toutes les branches, tags et l’historique.

git clone https://github.com/user/repo.git
git clone git@github.com:user/repo.git          # SSH transport (preferred for auth)
git clone --depth 1 https://github.com/user/repo.git  # Shallow clone (latest commit only)
git clone --branch develop https://github.com/user/repo.git  # Clone specific branch

Les clones superficiels (--depth) sont utiles pour les pipelines CI/CD où vous n’avez besoin que du dernier état, pas de l’historique complet. Ils réduisent considérablement le temps de clonage sur les grands dépôts, mais empêchent certaines opérations dépendant de l’historique comme git bisect.

Inspection de l’état

git status est la commande la plus fréquemment exécutée dans tout flux de travail. Elle affiche l’état à trois zones de votre dépôt.

git status
git status -s    # Short format: two-column status codes
git status -sb   # Short format with branch info

git diff compare le contenu entre les zones ou les commits.

git diff                    # Working directory vs. index (unstaged changes)
git diff --staged           # Index vs. last commit (what will be committed)
git diff HEAD               # Working directory vs. last commit (all changes)
git diff main..feature      # Compare tips of two branches
git diff abc123..def456     # Compare two specific commits
git diff --stat             # Show changed files and line counts only

git log parcourt le graphe de commits. Ses options de filtrage comptent parmi les fonctionnalités les plus puissantes et les moins utilisées de Git.

git log
git log --oneline --graph --decorate --all   # Visual branch graph
git log -p                                   # Show patch (diff) for each commit
git log --author="Jane"                      # Filter by author
git log --since="2 weeks ago"               # Filter by date
git log --grep="fix:"                        # Filter by commit message pattern
git log -- path/to/file                      # History of a specific file
git log --follow -- path/to/file             # Follow renames

La combinaison --graph --oneline --decorate --all est si universellement utile que la plupart des ingénieurs en créent un alias :

git config --global alias.lg "log --oneline --graph --decorate --all"

Staging et commit

git add filename.py          # Stage a specific file
git add src/                 # Stage an entire directory
git add .                    # Stage all changes in current directory
git add -p                   # Interactive patch staging (stage hunks, not whole files)
git add -u                   # Stage modifications and deletions, but not new files

Le staging interactif (git add -p) est l’une des fonctionnalités les plus puissantes et les moins utilisées de Git. Il vous permet de réviser et de mettre en staging sélectivement des hunks individuels dans un fichier, permettant des commits précis et atomiques même lorsque votre répertoire de travail contient plusieurs modifications non liées.

git commit -m "feat: add OAuth2 token refresh logic"
git commit --amend           # Modify the most recent commit (message or content)
git commit --amend --no-edit # Amend content without changing the message
git commit -v                # Open editor showing full diff of staged changes

Règle critique : Ne jamais modifier des commits qui ont déjà été poussés vers un remote partagé. La modification réécrit le hachage du commit, obligeant les collaborateurs à rebaser ou réinitialiser leurs branches locales.

Push et pull

git push origin main
git push origin feature/auth     # Push a specific branch
git push -u origin feature/auth  # Push and set upstream tracking
git push --force-with-lease      # Safer force push (fails if remote has new commits)
git push origin --delete old-branch  # Delete a remote branch
git push --tags                  # Push all local tags

Préférez --force-with-lease à --force lorsque vous devez réécrire l’historique distant. Il vérifie que personne d’autre n’a poussé depuis votre dernier fetch, évitant ainsi une perte accidentelle de données.

git pull origin main
git pull --rebase origin main    # Fetch and rebase instead of merge
git pull --ff-only               # Only fast-forward; abort if a merge commit would be created

git fetch télécharge les modifications distantes sans toucher à votre répertoire de travail ni à votre branche actuelle. C’est la méthode sûre pour inspecter les modifications en amont avant de les intégrer.

git fetch origin
git fetch --all          # Fetch from all remotes
git fetch --prune        # Remove remote-tracking branches that no longer exist upstream

Branches et fusions : le flux de travail central

Le modèle de branches de Git est sa fonctionnalité architecturale la plus significative. Une branche est simplement un pointeur nommé (un fichier de 41 octets dans .git/refs/heads/) vers un hachage de commit. La création d’une branche est instantanée quelle que soit la taille du dépôt.

Gestion des branches

git branch                        # List local branches
git branch -a                     # List all branches (local and remote-tracking)
git branch -v                     # List branches with last commit info
git branch feature/user-auth      # Create a new branch
git branch -d feature/user-auth   # Delete merged branch
git branch -D feature/user-auth   # Force delete (even if unmerged)
git branch -m old-name new-name   # Rename a branch

Changement de branche

Git moderne (2.23+) sépare les fonctions de git checkout en deux commandes dédiées :

git switch main                   # Switch to existing branch
git switch -c feature/payments    # Create and switch in one step
git restore filename.py           # Discard working directory changes to a file
git restore --staged filename.py  # Unstage a file (remove from index)

git checkout fonctionne toujours pour tout cela, mais git switch et git restore ont une sémantique plus claire et moins ambiguë et devraient être préférés dans les flux de travail modernes.

Stratégies de fusion

git merge feature/user-auth           # Standard merge (creates merge commit if needed)
git merge --no-ff feature/user-auth   # Always create merge commit (preserves branch topology)
git merge --squash feature/user-auth  # Squash all branch commits into one staged change
git merge --abort                     # Abort an in-progress conflicted merge

La fusion fast-forward se produit lorsque la branche cible n’a pas divergé de la source — Git déplace simplement le pointeur vers l’avant. Aucun commit de fusion n’est créé. --no-ff force un commit de fusion même dans ce cas, ce qui préserve l’historique visuel des branches de fonctionnalités dans git log --graph.

La fusion squash regroupe tous les commits d’une branche de fonctionnalité en une seule modification mise en staging, que vous commitez ensuite manuellement. Cela produit un historique linéaire propre sur main mais supprime l’historique de commits granulaire de la branche de fonctionnalité.

Rebase

git rebase rejoue les commits d’une branche sur une autre, réécrivant leurs hachages pour créer un historique linéaire.

git rebase main                  # Rebase current branch onto main
git rebase -i HEAD~5             # Interactive rebase: edit last 5 commits
git rebase --onto main server client  # Transplant client branch onto main, excluding server
git rebase --abort               # Abort a rebase in progress
git rebase --continue            # Continue after resolving a conflict

Le rebase interactif (-i) est l’outil d’hygiène de commits du professionnel. Il vous permet de réordonner, fusionner, modifier, supprimer ou diviser des commits avant de les partager. Cas d’utilisation courant : nettoyer une branche de fonctionnalité désordonnée avant d’ouvrir une pull request.

La règle d’or du rebase : Ne jamais rebaser des commits qui existent sur une branche publique partagée. Le rebase réécrit les hachages de commits. Si un coéquipier a basé son travail sur ces commits, son historique divergera et il devra faire face à une réconciliation difficile.

Résolution des conflits de fusion

Les conflits surviennent lorsque deux branches modifient la même région du même fichier. Git marque le conflit dans le fichier avec des marqueurs de conflit standard :

<<<<<<< HEAD
const timeout = 30000;
=======
const timeout = 60000;
>>>>>>> feature/increase-timeout

Flux de travail de résolution :

# After a conflicted merge or rebase
git status                    # Identify conflicted files (marked as "both modified")
# Edit each conflicted file, remove markers, keep correct content
git add resolved-file.js      # Mark as resolved
git commit                    # Complete the merge (message is pre-populated)

Pour les conflits complexes, un outil de fusion à trois voies offre une vue plus claire :

git mergetool                 # Launch configured merge tool (vimdiff, meld, etc.)
git config --global merge.tool vimdiff

Annulation des modifications : la matrice de décision

Choisir la mauvaise commande d’annulation est l’une des façons les plus courantes pour les développeurs de perdre du travail ou de corrompre l’historique partagé. Le bon choix dépend de deux variables : où se trouve la modification et si elle a été poussée.

git reset --soft HEAD~1      # Undo commit, keep changes in index
git reset HEAD~1             # Undo commit, keep changes in working dir
git reset --hard HEAD~1      # Undo commit, discard all changes permanently

git revert abc1234           # Create new commit that inverts abc1234
git revert HEAD~3..HEAD      # Revert last 3 commits (creates 3 revert commits)
git revert -n HEAD~3..HEAD   # Stage the reversals without committing (batch revert)

git reset --hard est irréversible par les commandes Git normales. Si vous l’exécutez accidentellement, votre seul chemin de récupération est git reflog, qui enregistre chaque position pointée par HEAD pendant environ 90 jours.

git reflog                   # Show HEAD movement history with hashes
git checkout -b recovery abc1234  # Recover by creating a branch at the lost commit

Commandes avancées pour les flux de travail en production

git stash

git stash sauvegarde l’état actuel de votre répertoire de travail et de l’index dans une pile, vous donnant un répertoire de travail propre pour changer de contexte.

git stash                        # Stash tracked changes
git stash -u                     # Include untracked files
git stash push -m "WIP: auth refactor"  # Stash with a descriptive name
git stash list                   # List all stash entries
git stash pop                    # Apply most recent stash and remove it from stack
git stash apply stash@{2}        # Apply specific stash without removing it
git stash drop stash@{2}         # Delete a specific stash entry
git stash branch feature/wip     # Create a new branch from a stash

git cherry-pick

git cherry-pick abc1234                    # Apply a single commit to current branch
git cherry-pick abc1234 def5678            # Apply multiple commits
git cherry-pick abc1234 --no-commit        # Apply changes without committing
git cherry-pick main~3..main              # Apply a range of commits

Cherry-pick est le mécanisme standard pour rétroporter des correctifs de bugs vers des branches de maintenance. Si vous corrigez une vulnérabilité de sécurité critique sur main, vous cherry-pickez ce commit sur v2.1-stable et v2.0-stable sans fusionner des fonctionnalités non liées.

git bisect

git bisect effectue une recherche binaire dans l’historique des commits pour trouver le commit exact qui a introduit un bug. C’est l’un des outils de débogage les plus puissants et les moins connus de Git.

git bisect start
git bisect bad                   # Mark current commit as broken
git bisect good v2.3.0           # Mark a known-good commit or tag
# Git checks out the midpoint commit automatically
# Test your code, then:
git bisect good                  # If this commit is fine
git bisect bad                   # If this commit is broken
# Repeat until Git identifies the first bad commit
git bisect reset                 # Return to original HEAD when done

Sur un dépôt avec 1 000 commits entre les points bon et mauvais, git bisect trouve le coupable en 10 étapes au maximum.

git tag

Les tags marquent des commits spécifiques comme significatifs — généralement des versions de publication.

git tag v1.4.2                          # Lightweight tag (just a pointer)
git tag -a v1.4.2 -m "Release 1.4.2"   # Annotated tag (recommended; stores metadata)
git tag -a v1.4.2 abc1234              # Tag a specific past commit
git push origin v1.4.2                 # Push a specific tag
git push origin --tags                 # Push all tags
git tag -d v1.4.2                      # Delete local tag
git push origin --delete v1.4.2        # Delete remote tag

Utilisez toujours des tags annotés pour les versions. Ils stockent le nom du tagueur, l’e-mail, la date et un message, et peuvent être signés avec GPG. Les tags légers ne sont appropriés que pour les signets locaux temporaires.

git worktree

git worktree permet d’extraire simultanément plusieurs répertoires de travail depuis le même dépôt — chacun sur une branche différente. Cela élimine le besoin de mettre en stash ou de committer le travail en cours lorsque vous devez passer à un correctif urgent.

git worktree add ../hotfix-branch hotfix/critical-auth-bug
git worktree list
git worktree remove ../hotfix-branch

Cela est particulièrement utile sur un Serveur Dédié exécutant un pipeline CI/CD où plusieurs tâches de build nécessitent un accès simultané à différentes branches du même dépôt sans interférer les unes avec les autres.

Flux de travail Git pour les équipes

La bonne stratégie de branches dépend de votre cadence de publication et de la taille de votre équipe. Trois modèles dominants existent :

Flux de travail par branche de fonctionnalité

Chaque fonctionnalité ou correctif vit sur sa propre branche. Les développeurs ouvrent des pull requests pour fusionner dans main. Simple et efficace pour la plupart des équipes.

Gitflow

Définit des branches main et develop à longue durée de vie, ainsi que des branches feature/, release/ et hotfix/ à courte durée de vie avec des règles de fusion strictes. Approprié pour les logiciels avec des versions explicites (bibliothèques, applications packagées).

Développement basé sur le tronc

Les développeurs commitent directement sur main (ou utilisent des branches très courtes fusionnées en moins d’un jour). Repose fortement sur les feature flags pour masquer le travail incomplet. Préféré par les équipes à haute vélocité pratiquant le déploiement continu.

Hébergement de dépôts Git : auto-hébergé vs. plateformes gérées

Pour les équipes qui exigent la souveraineté des données, la conformité ou une infrastructure privée, l’auto-hébergement d’un serveur Git est un choix viable et souvent nécessaire. Les options incluent Gitea (léger, basé sur Go), GitLab CE (plateforme DevOps complète) et Forgejo (fork de Gitea avec gouvernance communautaire).

Une instance Gitea auto-hébergée minimale fonctionne confortablement sur un plan VPS Hosting avec 2 vCPUs et 2 GB RAM. Pour les équipes plus grandes ou GitLab CE avec des runners CI, 4–8 GB RAM est le minimum pratique.

Lors de l’auto-hébergement, sécurisez votre serveur Git avec :

• Authentification par clé SSH (désactiver entièrement l’authentification par mot de passe)
• HTTPS avec un certificat valide — les Certificats SSL sont essentiels pour protéger les identifiants en transit
• Règles de pare-feu limitant l’exposition du port Git (22 ou port SSH personnalisé, 443 pour HTTPS)
• Sauvegardes automatisées régulières des répertoires de dépôts nus .git
• Secrets webhook pour les intégrations CI/CD

Pour les équipes utilisant des pipelines de déploiement basés sur Git qui gèrent également l’infrastructure web, associer un serveur Git auto-hébergé à un VPS avec cPanel vous offre des hooks de déploiement intégrés aux côtés d’outils de gestion d’hébergement familiers.

Hooks Git : automatisation des contrôles qualité

Les hooks Git sont des scripts qui s’exécutent automatiquement à des points spécifiques du cycle de vie Git. Ils résident dans .git/hooks/ et ne sont pas commités dans le dépôt par défaut (utilisez un outil comme pre-commit ou husky pour les partager).

Hooks clés pour les flux de travail en production :

# Example pre-commit hook: reject commits with debug print statements
#!/bin/bash
if git diff --cached | grep -E '^+.*(console.log|debugger|print("DEBUG)'; then
  echo "ERROR: Debug statement detected. Remove before committing."
  exit 1
fi

Le hook post-receive sur un dépôt serveur nu est le fondement du déploiement simple basé sur Git : poussez vers le serveur, le hook extrait le nouveau HEAD dans la racine web, exécute les étapes de build et redémarre les services — aucune plateforme CI externe requise.

.gitignore : garder les dépôts propres

Le fichier .gitignore indique à Git quels fichiers et motifs laisser non suivis. Il doit être commité dans le dépôt et maintenu avec soin.

# Dependencies
node_modules/
vendor/

# Build artifacts
dist/
build/
*.o
*.pyc
__pycache__/

# Environment and secrets — NEVER commit these
.env
.env.local
*.pem
*.key
config/secrets.yml

# IDE files
.idea/
.vscode/
*.swp

# OS files
.DS_Store
Thumbs.db

Piège critique : Si un fichier était déjà suivi avant d’être ajouté à .gitignore, Git continuera à le suivre. Vous devez explicitement le désindexer :

git rm --cached path/to/sensitive-file
git commit -m "chore: stop tracking secrets file"

Ne jamais commiter des identifiants, des clés API ou des clés privées dans un dépôt — même privé. Utilisez des variables d’environnement, des gestionnaires de secrets (HashiCorp Vault, AWS Secrets Manager) ou des fichiers .env qui sont .gitignore.

Optimisation des performances pour les grands dépôts

Git standard se dégrade sur les dépôts contenant des millions de fichiers ou des gigaoctets d’actifs binaires. Stratégies d’atténuation :

• Git LFS (Large File Storage) : Remplace les grands fichiers binaires par des fichiers pointeurs dans le dépôt et stocke le contenu réel sur un serveur LFS séparé. Essentiel pour les dépôts contenant des médias, des poids de modèles ML ou des binaires compilés.
• Clone partiel : git clone --filter=blob:none télécharge les commits et les arbres mais récupère les blobs à la demande. Réduit considérablement la taille du clone initial pour les grands monodépôts.
• Extraction fragmentée : git sparse-checkout set path/to/subdir extrait uniquement un sous-ensemble de l’arborescence de travail. Utile dans les monodépôts où un développeur ne travaille que dans un répertoire de service.
• Fichier commit-graph : git commit-graph write --reachable précalcule le graphe de commits, accélérant les opérations comme git log --graph et les requêtes d’accessibilité sur les grands historiques.
• git maintenance start : Planifie des tâches de maintenance en arrière-plan (compactage d’objets libres, mises à jour du commit-graph, préchargement fetch) pour maintenir la rapidité des opérations du dépôt dans le temps.

Liste de contrôle des points clés techniques

Avant de considérer votre configuration Git prête pour la production, vérifiez chacun des points suivants :

• Identité configurée : user.name et user.email correctement définis à la portée de configuration appropriée
• Clés SSH utilisées : Authentification par mot de passe vers les remotes remplacée par des paires de clés SSH ou HTTPS basé sur des tokens
• .gitignore commité : Secrets, artefacts de build et fichiers OS exclus avant le premier commit
• Branche par défaut nommée main : init.defaultBranch défini globalement pour éviter le nommage hérité master
• Les messages de commit suivent une convention : Commits conventionnels (feat:, fix:, chore:) ou format convenu par l’équipe imposé via le hook commit-msg
• git revert pour l’historique public : git reset --hard utilisé uniquement sur les commits locaux non poussés
• --force-with-lease plutôt que --force : Évite l’écrasement accidentel des pushes des coéquipiers
• Tags annotés pour les versions : git tag -a avec un message, pas des tags légers
• Hooks partagés via pre-commit ou husky : Contrôles qualité appliqués de manière cohérente dans toute l’équipe
• Git LFS configuré si le dépôt contient des actifs binaires supérieurs à 1 MB
• Dépôt nu sur le serveur : Remotes auto-hébergés initialisés avec git init --bare
• git fetch --prune régulier : Branches de suivi distant maintenues synchronisées avec l’état réel du remote

Foire aux questions

Quelle est la différence entre git fetch et git pull ?

git fetch télécharge les commits, branches et tags du remote dans vos refs de suivi distant locaux (par ex., origin/main) sans toucher à votre répertoire de travail ni à votre branche actuelle. git pull est git fetch suivi immédiatement de git merge (ou git rebase si configuré). Utilisez git fetch lorsque vous souhaitez inspecter les modifications en amont avant de les intégrer.

Quand devrais-je utiliser git rebase plutôt que git merge ?

Utilisez rebase pour linéariser votre branche de fonctionnalité locale avant d’ouvrir une pull request, en gardant l’historique du projet lisible. Ne rebasez jamais une branche que d’autres développeurs ont déjà clonée ou sur laquelle ils ont basé leur travail — réécrire des hachages de commits publiés oblige tout le monde à réconcilier manuellement des historiques divergents.

Comment supprimer définitivement un fichier sensible qui a été commité accidentellement ?

Utilisez git filter-repo (le remplacement moderne de git filter-branch) : git filter-repo --path secrets.env --invert-paths. Cela réécrit l’intégralité de l’historique du dépôt, supprimant le fichier de chaque commit. Après la réécriture, forcez le push de toutes les branches et tags, puis faites pivoter immédiatement les identifiants exposés — considérez-les comme compromis quelle que soit la rapidité de votre intervention.

Qu’est-ce que l’état HEAD détaché et comment s’en remettre ?

HEAD détaché signifie que votre pointeur HEAD référence directement un hachage de commit spécifique plutôt qu’un nom de branche. Tout commit que vous effectuez n’appartiendra à aucune branche et deviendra inaccessible après que vous ayez changé de branche. Pour récupérer : git switch -c new-branch-name pour attacher les commits à une nouvelle branche, ou git switch main pour les supprimer.

Comment Git gère-t-il les fichiers binaires différemment des fichiers texte ?

Git stocke les fichiers binaires comme des blobs opaques — il ne peut pas calculer des diffs significatifs au niveau des lignes ni effectuer des fusions automatiques sur eux. Les conflits dans les fichiers binaires doivent être résolus en choisissant entièrement une version. Pour les dépôts contenant des actifs binaires importants, configurez Git LFS pour stocker les binaires en externe et garder le dépôt lui-même léger et rapide.