Ressources · Intégration n8n

Nœud Git n8nConfigurer Git dans n8n.

Le nœud Git n8n exécute des commandes git sur un dépôt posé sur le disque de ton instance. Il embarque 15 opérations, de clone à commit en passant par log, tag et switch branch, toutes accrochées à un chemin de dépôt. Utile dès qu'un workflow produit des fichiers qui méritent un historique.

Avis vérifiés sur Trustpilot · Agence IA, automatisation & growth

Pourquoi automatiser

À quoi sert vraiment le nœud Git n8n ?

Git fait partie des nœuds core livrés avec n8n : il enveloppe la ligne de commande git autour d'un dépôt rangé sur un chemin que l'instance peut lire et écrire. Une opération par nœud, un chemin de dépôt, et n8n fait ce qu'un développeur taperait dans son terminal. Rien à installer, aucun surcoût côté n8n, que tu sois sur n8n Cloud ou sur une instance auto-hébergée.

Premier terrain de jeu, le plus fréquent : garder la trace des fichiers qu'un workflow fabrique. Un export tombe chaque nuit dans un dossier, Add indexe les chemins concernés, Commit enregistre le changement avec un message, Push l'envoie sur le dépôt distant. Trois nœuds, et chaque export devient une différence lisible des semaines plus tard.

Deuxième usage, en lecture cette fois. Log renvoie l'historique des commits d'un dépôt ou d'un seul fichier, Status dit ce qui a bougé depuis le dernier commit, Reflog retrace les positions successives d'une référence. Cette sortie se dirige ensuite vers un Switch selon ce qui a changé, ou se recoupe avec une autre source grâce à Merge avant d'atterrir dans un rapport.

Troisième cas, préparer une copie de travail. Clone rapatrie un dépôt dans un dossier neuf, Switch Branch se place sur la branche du job, Add Config et User Setup fixent l'identité sous laquelle les commits seront écrits. Au bout de la chaîne, un dossier vide est devenu un dépôt exploitable par le workflow suivant.

Vient la limite, et elle est nette. Ce nœud parle à git, pas à GitHub ni à GitLab. Ouvrir une pull request, commenter un ticket, lire un dépôt via une API web : rien de tout ça n'est à sa portée, et c'est HTTP Request ou un nœud dédié qui prend le relais sur ces appels HTTP. Autre contrainte : le dépôt doit exister sur un système de fichiers accessible à l'instance, donc en pratique une instance auto-hébergée avec un volume monté.

Deux détails à connaître avant de construire. Le nœud s'exécute sur chaque item entrant : huit chemins de fichiers arrivés d'une étape précédente déclenchent huit actions git, sauf si tu les regroupes avant. Et il n'ouvre jamais un workflow, un déclencheur le précède toujours, Schedule Trigger, Webhook ou le trigger d'un outil. Pour aller plus loin sur la plateforme elle-même, l'Avis n8n et la Formation n8n prennent le sujet par le haut.

Connexion

Qu'est-ce qu'il faut authentifier ?

  1. 01

    Choisir le mode d'authentification

    Deux opérations affichent un sélecteur Authentication, Clone et Push, avec deux valeurs possibles : gitPassword (Authenticate) et none (None). None convient quand le dépôt distant est public ou quand il s'agit d'un chemin local. Authenticate devient nécessaire dès que le distant réclame un compte. Les autres opérations travaillent en local et ne posent pas la question.

  2. 02

    Créer le credential Git

    Avec Authenticate, le nœud demande un Credential for Git, c'est-à-dire un jeu d'identifiants enregistré dans n8n. Il se crée une seule fois depuis le menu Credentials, puis se réutilise dans tous les workflows qui en ont besoin. Ce credential fonctionne en basic auth et contient deux champs : un Username et un Password valables sur GitHub, GitLab ou une plateforme équivalente.

  3. 03

    Désigner le dépôt de travail

    Chaque opération réclame un Repository Path, le chemin local du dépôt git sur la machine qui fait tourner n8n. Clone sort du lot : il attend un New Repository Path pour le dossier de destination et un Source Repository pour l'URL ou le chemin à copier. Ce chemin peut venir d'une étape précédente sous forme d'expression, la syntaxe n8n qui va chercher un champ de l'item : {{ $json.path }}.

Actions

Quelle opération Git choisir ?

Le nœud Git expose 15 opérations. Pour chacune : le nœud tel que tu le configures dans n8n, les champs obligatoires, et nos notes de terrain.

01

Add a file or folder to commit

add

Ce que tu vois dans n8n

Notes & cas d'usage

Avant d'enregistrer quoi que ce soit, git veut savoir quels fichiers entrent dans le lot. Cette opération fait exactement ça : elle indexe des fichiers ou des dossiers pour le commit suivant.

Paramètres clés

  • Paths to Add : la liste de chemins séparés par des virgules, requise, absolus ou relatifs au Repository Path, placeholder README.md.
  • Repository Path : le chemin local du dépôt git concerné.
Cas d'usage
un workflow dépose un CSV généré dans le dossier du dépôt, et ce nœud n'indexe que ce fichier pour que le commit reste propre.
02

Add configuration property

addConfig

Ce que tu vois dans n8n

Notes & cas d'usage

La configuration d'un dépôt tient dans des paires clé/valeur. Cette opération en écrit une dans la configuration locale.

Paramètres clés

  • Key : le nom de la clé à définir, requis, placeholder user.email.
  • Value : la valeur à enregistrer, requise, placeholder name@example.com.
  • Mode : option à deux choix, set pour remplacer le réglage et append pour l'ajouter plutôt que l'écraser.
Cas d'usage
juste après un clone, un premier nœud inscrit l'adresse sous laquelle un robot signera ses commits, avant même d'indexer un fichier.
03

Clone a repository

clone

Ce que tu vois dans n8n

Notes & cas d'usage

Là où presque toutes les opérations supposent un dépôt déjà présent, celle-ci le crée en copiant un dépôt distant dans un dossier local.

Paramètres clés

  • New Repository Path : le chemin local de destination, requis, placeholder /tmp/repository.
  • Source Repository : l'URL ou le chemin du dépôt à copier, requis, placeholder https://github.com/n8n-io/n8n.
  • Authentication : Authenticate pour transmettre un credential, None pour cloner sans.
Cas d'usage
un job planifié clone un dépôt de modèles dans un dossier temporaire, y lit ce dont il a besoin, et laisse le dossier disparaître.
04

Commit files or folders to git

commit

Ce que tu vois dans n8n

Notes & cas d'usage

Voilà l'opération qui transforme des changements indexés en entrée définitive de l'historique, avec un message pour l'expliquer.

Paramètres clés

  • Message : le message du commit, non requis par le nœud, même si un historique sans message se relit très mal.
  • Branch : option qui indique la branche sur laquelle basculer avant de committer, placeholder main ; vide, le commit reste sur la branche courante.
  • Paths to Add : option listant les chemins à committer, placeholder /data/file1.json ; non renseignée, tout ce qui est indexé passe.
Cas d'usage
un export quotidien signe son commit avec la date du run.
05

Fetch from remote repository

fetch

Ce que tu vois dans n8n

Notes & cas d'usage

Récupérer sans rien modifier : le fetch télécharge ce que connaît le dépôt distant et laisse la copie de travail intacte.

Cas d'usage
un workflow de surveillance fait un fetch, puis un Log pour voir si quelque chose est apparu côté distant pendant la nuit, et s'arrête là si la réponse est non. Aucun fichier local ne bouge, donc le nœud peut tourner en boucle sans risque.
06

Return current configuration

listConfig

Ce que tu vois dans n8n

Notes & cas d'usage

Pendant symétrique de l'écriture de configuration : cette opération renvoie les réglages actuellement appliqués au dépôt.

Cas d'usage
après un clone, une vérification confirme que l'identité est bien en place avant qu'un nœud Commit ne s'exécute, ce qui évite l'échec en bout de chaîne. La sortie reste de la donnée comme une autre, un nœud suivant peut donc tester une valeur précise.
07

Return git commit history

log

Ce que tu vois dans n8n

Notes & cas d'usage

Ici l'historique devient de la donnée exploitable : l'opération renvoie les commits, et la pagination décide combien.

Paramètres clés

  • Return All : activé, n8n renvoie tous les commits ; désactivé, il s'arrête à Limit.
  • Limit : le nombre maximum de commits renvoyés, disponible seulement quand Return All est désactivé.
  • File : option contenant le chemin d'un fichier ou d'un dossier, absolu ou relatif au Repository Path, pour n'obtenir que son historique.
Cas d'usage
un récapitulatif hebdomadaire remonte les commits qui ont touché un fichier de configuration sensible.
08

Pull from remote repository

pull

Ce que tu vois dans n8n

Notes & cas d'usage

Contrairement au fetch, le pull applique les changements distants à la copie de travail : les fichiers sur le disque finissent alignés sur le dépôt distant.

Cas d'usage
un workflow qui lit des gabarits partagés fait un pull avant de lire, histoire d'avoir la modification qu'un collègue a poussée ce matin. Comme les fichiers changent, réserve ce dossier à un seul job à la fois.
09

Push to remote repository

push

Ce que tu vois dans n8n

Notes & cas d'usage

Un commit reste strictement local tant que cette opération ne l'a pas envoyé, et c'est le second endroit où l'authentification apparaît.

Paramètres clés

  • Authentication : Authenticate pour transmettre un Credential for Git, None pour pousser sans credential.
  • Branch : option précisant la branche sur laquelle basculer avant le push, placeholder main ; vide, c'est la branche courante qui part.
  • Target Repository : option contenant l'URL ou le chemin du dépôt visé, placeholder https://github.com/n8n-io/n8n.
Cas d'usage
dernier nœud d'un workflow de publication, une fois le commit confirmé.
10

Push tags to remote repository

pushTags

Ce que tu vois dans n8n

Notes & cas d'usage

Un push ordinaire laisse les tags derrière lui, et cette opération comble précisément ce manque.

Cas d'usage
un workflow de release crée un tag, pousse les commits, puis exécute ce nœud pour que le tag apparaisse aussi côté distant. À enchaîner avec l'opération Tag dans le même run, sinon il n'y a rien de neuf à envoyer et le nœud ne produit aucun effet visible.
11

Return reference log

reflog

Ce que tu vois dans n8n

Notes & cas d'usage

Quand Log liste des commits, le reference log liste les positions successives d'une référence : c'est ainsi qu'on retrouve où une branche est passée.

Paramètres clés

  • Reference : option nommant la référence à inspecter, un nom de branche par exemple ; vide, c'est HEAD qui est pris, placeholder HEAD.
  • Return All : activé, toutes les entrées reviennent ; désactivé, le résultat s'arrête à Limit.
  • Limit : le nombre maximum d'entrées renvoyées.
Cas d'usage
un audit consigne les déplacements récents d'une branche de release à côté des commits eux-mêmes.
12

Return status of current repository

status

Ce que tu vois dans n8n

Notes & cas d'usage

Status répond à une seule question : qu'est-ce qui diffère en ce moment entre la copie de travail et le dernier commit.

Cas d'usage
un garde-fou placé avant le Commit, pour que le workflow continue seulement si quelque chose a réellement changé, et que l'historique ne se remplisse pas de commits vides. C'est aussi le premier réflexe quand un job planifié a échoué et que personne ne sait dans quel état le dossier a été laissé.
13

Switch to a different branch

switchBranch

Ce que tu vois dans n8n

Notes & cas d'usage

La gestion des branches a son opération dédiée, et ses options couvrent aussi bien la création que le simple déplacement.

Paramètres clés

  • Branch Name : le nom de la branche visée, requis, placeholder feature/new-feature.
  • Create Branch If Not Exists et Start Point : créer la branche si elle n'existe pas, à partir du commit, de la branche ou du tag donné, ou depuis le HEAD courant.
  • Force Switch, Set Upstream et Remote Name : forcer le passage en abandonnant les modifications locales, suivre une branche distante, nommer le distant à suivre, placeholder origin.
Cas d'usage
un job ouvre une branche datée à chaque exécution.
14

Create a new tag

tag

Ce que tu vois dans n8n

Notes & cas d'usage

Un tag pose un nom sur l'état courant du dépôt : c'est ce qui donne à une version quelque chose de lisible auquel se référer.

Paramètres clés

  • Name : le nom du tag à créer, requis.
Cas d'usage
un workflow de build étiquette le dépôt avec le numéro de version reçu à l'étape précédente, puis passe la main à Push Tags pour que ce nom rejoigne le distant. L'opération ne prenant qu'un nom, la valeur arrive presque toujours sous forme d'expression plutôt que saisie à la main.
15

Set up a user

userSetup

Ce que tu vois dans n8n

Notes & cas d'usage

Tout commit porte un auteur. Cette opération règle l'utilisateur du dépôt sans avoir à détailler les clés de configuration.

Cas d'usage
premier nœud après un clone, pour que les commits suivants soient attribués au lieu d'être refusés faute d'identité. Quand il faut maîtriser la clé exacte qui sera écrite, c'est Add Config, avec son couple Key et Value, qui reprend la main.
Besoin d'aide

Besoin d'aide pour automatiser Git avec n8n ?

L'équipe te répond directement.

Chaque message est lu par une personne.

FAQ

Git et n8n, les questions fréquentes

01Le nœud Git n8n est-il gratuit ?
Oui. Git est un nœud core, livré avec n8n : rien à installer, aucun surcoût côté n8n. Il est disponible sur n8n Cloud, l'offre hébergée par n8n, comme sur une instance auto-hébergée installée via Docker ou npm, en Community Edition sous licence Sustainable Use. Un workflow construit d'un côté se comporte de la même façon de l'autre. Ce qui peut rester payant se situe en dehors de n8n : le compte utilisé sur GitHub, GitLab ou une plateforme équivalente dépend des conditions de cette plateforme, et cette page n'en dit rien.
02Quels identifiants faut-il pour le nœud Git ?
Ça dépend de l'opération. Clone et Push affichent un sélecteur Authentication avec deux valeurs, Authenticate et None, et ce sont les deux seules opérations capables de transmettre un credential. En choisissant Authenticate, il faut sélectionner ou créer un Credential for Git : il fonctionne en basic auth et stocke un Username et un Password pour GitHub, GitLab ou une plateforme similaire. Ce credential se crée une fois depuis le menu Credentials et se réutilise partout. Toutes les autres opérations travaillent sur le dépôt local désigné par Repository Path, sans aucun identifiant.
03Quelles sont les limites du nœud Git ?
La principale tient à son périmètre. Le nœud couvre 15 opérations git sur un dépôt posé sur le disque, et il s'arrête là. Il ne dialogue pas avec l'API web d'une plateforme d'hébergement : pull requests, tickets et réglages de dépôt lui échappent. Le dépôt doit par ailleurs se trouver sur un système de fichiers que l'instance peut lire et écrire, ce qui exclut un montage purement distant. Seule la basic auth est acceptée pour Clone et Push. Enfin, le nœud s'exécute sur chaque item entrant : un lot d'items égale un lot d'actions git.
04Nœud Git ou HTTP Request pour automatiser un dépôt ?
La question à se poser est : à qui parles-tu. Si l'action relève de git lui-même, cloner, committer, taguer, pousser, le nœud Git la réalise directement en lisant le dépôt sur le disque. Si l'action appartient à la plateforme qui héberge le dépôt, ouvrir une pull request ou lister des tickets par exemple, il s'agit d'une API HTTP et c'est HTTP Request qui convient. Les deux cohabitent très bien dans un même workflow : commit et push avec Git, puis un appel HTTP pour ce que git n'a jamais su faire. HTTP Request reste réservé aux endpoints HTTP.
05n8n ou Make pour automatiser git ?
Les deux sont des plateformes d'automatisation visuelles, et l'écart se joue sur trois points. L'hébergement d'abord : Make fonctionne uniquement en hébergé, n8n s'auto-héberge aussi via Docker ou npm. Ce point pèse lourd ici, puisque le nœud Git a besoin d'un dépôt sur un système de fichiers accessible, bien plus simple à organiser sur sa propre instance. La maîtrise des données suit la même logique, dépôt et credential restant sur ton infrastructure. Le modèle de coût diffère également, Make étant facturé à l'opération. L'avis complet est lié plus haut dans la page.
Hack'celeration Lab

Reçois nos tips intégration chaque semaine.

Pas de spam. Désinscription à tout moment.