Git patch : partager des modifications entre repos

Quand tu dois appliquer la même modification sur plusieurs repos qui partagent une base de code commune, transporter un commit d’un dépôt à l’autre avec git format-patch évite de le recréer à la main.

Le résultat, c’est un fichier .patch qui se partage comme n’importe quelle pièce jointe.

Créer le patch

git format-patch -k -1 HEAD -o ./patches/

• -k : conserve le message du commit tel quel, sans ajouter le préfixe [PATCH]
• -1 : un seul commit (le dernier). Remplace par -3 pour les 3 derniers, ou donne un SHA précis
• -o ./patches/ : dossier de sortie, plus propre qu’un >> à la main

Pour une plage de commits :

git format-patch -k main..ma-branche -o ./patches/

Ça génère un fichier .patch numéroté par commit, dans l’ordre.

Appliquer le patch

git apply patches/0001-mon-fix.patch

git apply applique les changements sans créer de commit. Utile pour inspecter d’abord.

Si tu veux rejouer le commit complet avec l’auteur et le message d’origine :

git am patches/0001-mon-fix.patch

C’est le comportement le plus courant.

Vérifier avant d’appliquer

git apply --check patches/0001-mon-fix.patch

Vérifie que le patch s’applique proprement sans toucher au working tree. Ça évite de se retrouver avec un conflit à démêler.

En cas de conflit

Si git am accroche :

# Résoudre les conflits dans les fichiers concernés, puis :
git add .
git am --continue

# Ou annuler proprement :
git am --abort

Les limites à connaître

Le contexte doit correspondre

Un patch est généré contre un état précis du code. Si le repo cible a divergé (fichiers renommés, lignes déplacées), git apply va échouer ou produire des conflits. Plus les repos ont évolué différemment, plus c’est fragile.

Pas de garantie de cohérence

Contrairement à une branche ou une MR, un patch ne vérifie pas que les dépendances sont satisfaites. Tu peux appliquer un patch qui référence une fonction qui n’existe pas encore dans le repo cible. Le code compile mais plante à l’exécution.

Pas fait pour le long terme

Si tu te retrouves à propager régulièrement des patches entre plusieurs repos, c’est souvent le signe que l’architecture mérite d’être revue : un module partagé, un repo commun, ou une gestion via des git submodules. Le patch reste un outil ponctuel, pas un workflow de synchronisation.

Perte de contexte sur les gros historiques

git am rejoue les commits un par un. Sur une longue série, si l’un échoue, tu te retrouves à mi-chemin avec un état partiel à démêler. Mieux vaut travailler par petits lots.

Quand l’utiliser

C’est utile dans quelques cas précis :

• Propager un hotfix entre des repos qui partagent du code mais n’ont pas de remote commun
• Travailler avec quelqu’un qui n’a pas accès au dépôt
• Environments air-gapped où tu ne peux pas faire de git pull depuis l’extérieur
• Archiver un changement spécifique sous forme de fichier

Pour le reste (branches normales, PR, MR), le workflow Git classique reste plus adapté.