Resources · n8n integration

n8n Git nodeConfigure Git in n8n.

The n8n Git node drives a git repository that your n8n instance can reach on disk. It carries 15 operations, from clone and commit through to log, tag and switch branch, and every one of them starts from a Repository Path. Built for teams whose workflows write files worth versioning.

Try the Git node on n8nSee the 15 operations

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n Git node actually do?

The Git node is a core node shipped with n8n, and it wraps the git command line around a repository stored at a path the n8n instance can read and write. You pick one operation per node, point it at a Repository Path, and n8n performs the same action a developer would type in a terminal. Nothing is installed, and it costs nothing beyond n8n itself, on n8n Cloud as well as on a self-hosted instance.

Start with the scenario most teams land on first: a workflow produces files, and those files need a history. A nightly export lands in a folder, Add stages the paths, Commit writes the change with a message, Push sends it to the remote. Three nodes, and every export becomes a diff someone can read a month later.

The second scenario reads instead of writes. Log returns the commit history of a repository or of a single file, Status reports what changed since the last commit, and Reflog shows where a reference has pointed over time. Feed that output into If to branch on whether anything moved, or reshape it with Edit Fields (Set) before it reaches a report.

The third one is about preparing a working copy. Clone pulls a repository into a fresh local path, Switch Branch moves to the branch a job should work on, and Add Config plus User Setup settle the identity commits are written under. That sequence turns an empty folder into a repository a later workflow can commit to.

Now the honest limit. This node talks to git, not to GitHub, GitLab or any hosting product. Opening a pull request, commenting on an issue or reading a repository through a web API is out of scope, and that is where HTTP Request or a dedicated node takes over. The node also needs the repository to exist on a filesystem the n8n instance can reach, which in practice means a self-hosted instance with a mounted volume.

Two more things worth knowing before you build. The node runs once per incoming item, so a list of ten file paths arriving from a previous step means ten git actions unless you collapse them first. And it does not start a workflow on its own: a Schedule Trigger, a Webhook or another tool's trigger has to come first. If you are still choosing your automation platform, the n8n review covers that decision in depth.

Connect

What do you need to authenticate?

  1. 01

    Choose an authentication mode

    Clone and Push both show an Authentication selector with two values, gitPassword (Authenticate) and none (None). Pick None when the repository is public or when the remote is a local path, and pick Authenticate when the remote demands an account. The other operations work on the local repository and never ask the question.

  2. 02

    Create the Git credential

    With Authenticate selected, the node asks for a Credential for Git. Create it once from the Credentials menu in n8n, where it is stored under your account and reused by every workflow that needs it. The credential uses basic auth and holds two fields, a Username and a Password for GitHub, GitLab or a similar platform.

  3. 03

    Point the node at a repository

    Every operation asks for a Repository Path, the local path of the git repository on the machine running n8n. Clone is the exception in shape: it takes a New Repository Path for the destination folder and a Source Repository for the URL or path being copied. A path can come from a previous step as an expression, written {{ $json.path }}.

Actions

Which Git operation should you pick?

The Git node exposes 15 operations. For each one: the node as you configure it in n8n, the required fields, and our field notes.

01

Add a file or folder to commit

add

What you see in n8n

Notes & use cases

Staging comes before committing, and this operation is the staging step. It marks files or folders so that a later Commit includes them in the snapshot.

Key parameters

  • Paths to Add: a required comma separated list of paths, absolute or relative to the Repository Path, shown with the placeholder README.md.
  • Repository Path: the local path of the git repository the staging applies to.
Use cases
a workflow writes a generated CSV into the repository folder, and this node stages that one file so the commit stays focused instead of sweeping up everything else lying around.
02

Add configuration property

addConfig

What you see in n8n

Notes & use cases

Git keeps settings as key and value pairs, and this operation writes one of them into the local config of the repository.

Key parameters

  • Key: the required name of the key to set, with user.email as the placeholder.
  • Value: the required value to store, placeholder name@example.com.
  • Mode: an option with two choices, set to overwrite the setting and append to add to it rather than replace it.
Use cases
a freshly cloned repository has no identity attached, so a first node writes the email a bot should commit under before any file is staged.
03

Clone a repository

clone

What you see in n8n

Notes & use cases

Where most operations expect a repository to already sit on disk, this one creates it by copying a remote into a local folder.

Key parameters

  • New Repository Path: the required local path the repository gets cloned into, placeholder /tmp/repository.
  • Source Repository: the required URL or path of the repository being copied, placeholder https://github.com/n8n-io/n8n.
  • Authentication: Authenticate to pass a credential in, None to clone without one.
Use cases
a scheduled job clones a documentation repository into a temporary folder, reads what it needs, and lets the folder disappear after the run.
04

Commit files or folders to git

commit

What you see in n8n

Notes & use cases

This is the operation that turns staged changes into a permanent entry in the history, with a message attached to it.

Key parameters

  • Message: the commit message, not required by the node, though a history without messages is hard to read later.
  • Branch: an option naming the branch to switch to before committing, placeholder main; left empty, the commit lands on the current branch.
  • Paths to Add: an option listing paths to commit, placeholder /data/file1.json; unset, every added file and folder goes in.
Use cases
a daily export commits with a message built from the run date so the history reads like a log.
05

Fetch from remote repository

fetch

What you see in n8n

Notes & use cases

Fetching downloads what the remote knows without touching the files in your working copy, which makes it the safe way to look before you merge.

Use cases
a monitoring workflow fetches first, then runs Log to see whether anything new appeared upstream overnight, and stops there if the answer is no. Nothing local changes, so the node is harmless to run on a schedule.
06

Return current configuration

listConfig

What you see in n8n

Notes & use cases

Reading the config back is the counterpart to writing it: this operation returns the settings currently applied to the repository.

Use cases
after a clone, a check confirms that the identity keys are in place before a commit node runs, which avoids a failed run at the end of a long workflow. The output is data like any other, so a later node can test a single value.
07

Return git commit history

log

What you see in n8n

Notes & use cases

History becomes workflow data here: the operation returns commits, and pagination decides how many of them.

Key parameters

  • Return All: on, n8n returns every commit; off, it stops at Limit.
  • Limit: the maximum number of commits returned, available only while Return All is off.
  • File: an option holding the path of a file or folder, absolute or relative to the Repository Path, to get the history of that path alone.
Use cases
a weekly digest pulls the recent commits touching one configuration file and posts the result where the team reads it.
08

Pull from remote repository

pull

What you see in n8n

Notes & use cases

Unlike Fetch, this one brings the remote changes into the working copy, so the files on disk end up matching what the remote holds.

Use cases
a workflow that reads templates from a shared repository pulls before it reads, so a colleague's change from this morning is already there. Since the working copy changes, run it on a folder no other job is writing to at the same moment.
09

Push to remote repository

push

What you see in n8n

Notes & use cases

Local commits stay local until this operation sends them to the remote, and it is the second place where authentication appears.

Key parameters

  • Authentication: Authenticate to pass a Credential for Git in, None to push without one.
  • Branch: an option naming the branch to switch to before pushing, placeholder main; empty, the current branch is pushed.
  • Target Repository: an option holding the URL or path to push to, placeholder https://github.com/n8n-io/n8n.
Use cases
the last node of a publishing workflow pushes the branch a report was committed to, once the commit step reports success.
10

Push tags to remote repository

pushTags

What you see in n8n

Notes & use cases

Tags do not travel with an ordinary push, which is exactly the gap this operation fills. It sends the tags of the repository at the Repository Path to the remote.

Use cases
a release workflow creates a tag, pushes its commits, then runs this node so the name shows up on the remote as well. Pair it with Tag in the same run. Otherwise nothing new is waiting to be sent, and the node quietly does nothing at all.
11

Return reference log

reflog

What you see in n8n

Notes & use cases

Where Log lists commits, the reference log lists where a reference has pointed over time, which is how you retrace a branch that moved.

Key parameters

  • Reference: an option naming the reference to show the reflog for, a branch name for instance; left empty it uses HEAD, placeholder HEAD.
  • Return All: on, every entry comes back; off, the result stops at Limit.
  • Limit: the maximum number of entries to return.
Use cases
an audit workflow records the recent movements of a release branch alongside the commits themselves.
12

Return status of current repository

status

What you see in n8n

Notes & use cases

Status answers one question, what is different right now between the working copy and the last commit.

Use cases
a guard node runs before Commit, and the workflow only continues when something actually changed, which keeps empty commits out of the history. It also makes a useful first step when a scheduled job fails and nobody knows what state the folder was left in.
13

Switch to a different branch

switchBranch

What you see in n8n

Notes & use cases

Branch handling gets its own operation, and its options cover creating the branch as well as moving to it.

Key parameters

  • Branch Name: the required name of the branch to switch to, placeholder feature/new-feature.
  • Create Branch If Not Exists and Start Point: create the branch when it is missing, from the commit, branch or tag given as start point, or from the current HEAD.
  • Force Switch, Set Upstream and Remote Name: force the move and discard local changes, track a remote branch, name the remote to track, placeholder origin.
Use cases
a job opens a dated branch per run before writing any file.
14

Create a new tag

tag

What you see in n8n

Notes & use cases

A tag pins a name onto the current state of the repository, which is how a specific version gets something readable to refer to.

Key parameters

  • Name: the required name of the tag to create.
Use cases
a build workflow tags the repository with a version string it received from a previous step, then hands over to Push Tags so the name reaches the remote. Since the operation takes only a name, the value usually arrives as an expression rather than typed by hand.
15

Set up a user

userSetup

What you see in n8n

Notes & use cases

Commits carry an author, and this operation sets the user for the repository without you having to spell out config keys.

Use cases
the first node after a clone, so that later commits are attributed rather than rejected for a missing identity. When you need control over the exact key that gets written, Add Config is the operation that takes a Key and a Value instead.
Need help

Need help automating Git with n8n?

A person reads every message.

FAQ

Git and n8n, questions people ask

01Is the n8n Git node free to use?
Yes. Git is a core node, shipped with n8n itself, so there is nothing to install and no extra cost on n8n's side. It is available on n8n Cloud, the hosted offer run by n8n, and on a self-hosted instance installed through Docker or npm under the Community Edition and its Sustainable Use licence. A workflow built in one place behaves the same in the other. What you may still pay for sits outside n8n: the account you use on GitHub, GitLab or a similar platform follows that platform's own terms, and this page says nothing about it.
02What credentials does the Git node need?
It depends on the operation. Clone and Push carry an Authentication selector with two values, Authenticate and None, and only those two operations can pass a credential. Choosing Authenticate means selecting or creating a Credential for Git, which uses basic auth and stores a Username and a Password for GitHub, GitLab or a similar platform. The credential is created once from the Credentials menu in n8n and reused across workflows. Every other operation works against the local repository at the Repository Path and needs no credential at all.
03What are the limits of the Git node in n8n?
The main one is scope. The node covers 15 git operations against a repository on disk, and that is where it stops. It does not talk to the web API of a hosting platform, so pull requests, issues and repository settings are not reachable from it. The repository also has to live on a filesystem the n8n instance can read and write, which rules out a purely remote setup. Only basic auth is supported for Clone and Push, and the node runs once per incoming item, so a batch of items means a batch of git actions.
04Git node or HTTP Request for repository automation?
Ask what you are talking to. If the action is a git action, cloning, committing, tagging, pushing, the Git node does it directly and reads the repository on disk. If the action belongs to the platform hosting the repository, opening a pull request or listing issues for example, that is an HTTP API and HTTP Request is the right node for it. The two often sit in the same workflow: commit and push with Git, then call the platform over HTTP for everything git itself never knew about. HTTP Request is a fallback for HTTP endpoints only, never for another protocol.
05n8n or Make for git automation?
Both are visual automation platforms, and the difference shows up in three places. Hosting: Make runs hosted only, while n8n also self-hosts through Docker or npm. That matters a lot here, because the Git node needs a repository on a filesystem it can reach, which is far easier to arrange on your own instance. Data control follows the same line, since a self-hosted instance keeps the repository and its credential on your infrastructure. Cost models differ too, Make billing per operation. Our full comparison lives in the n8n review linked above.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.

Same platform

Other docs you might need on this stack.

Browse all integrations