GitHub n8n integrationAutomate GitHub with n8n.

Commits a new file into the repository. The content comes either from text you type or from a binary field produced by an earlier node, so a generated PDF travels the same path as a Markdown page.

• File Path: the full path inside the repository, docs/README.md style, not just the file name.
• Binary File: switches the source. Off, n8n takes File Content; on, it takes the file sitting in Input Binary Field.
• Commit Message: the line that shows up in the repository history, so make it say which workflow wrote the file.

Removes a file from the repository and records the removal as a commit, like any other change.

• File Path: the complete path of the file to remove; when it comes from a previous node, an expression such as {{ $json.filePath }} saves you from hardcoding it.
• Commit Message: required here too, and the only explanation the log will ever carry.

Writes new content over a file that already exists and commits the result. Same two sources as the create operation, text or binary, with one difference that matters: the file has to be there.

• File Path: points at the file to change, complete from the repository root, docs/README.md rather than README.md.
• File Content: the new text, usually built by the node just before.
• Binary File with Input Binary Field: the other route, when the new version arrives as binary data.
• Commit Message: required.

Pulls a single file out of the repository and hands it to the next node. You get the raw API response by default; turn As Binary Property on and the file arrives as binary data instead, ready to be attached or uploaded somewhere else.

• File Path: the full path of the file to read.
• Put Output File in Field: the name of the output binary field that will hold the file.
• Reference, in Additional Parameters: a commit, branch or tag name. Left empty, GitHub reads the default branch of the repository, usually master.

Lists what a folder contains, one item per entry. That is how a workflow loops over a directory whose content it cannot know in advance.

• File Path: the folder to read, given as a complete path from the repository root; the field carries the same label as in the other file operations.

Opens a new issue in the repository and returns it, including the number that every later operation on that ticket will ask for.

• Title: the only required field, and the line people read in the issue list.
• Body: optional, and in practice where the error message, the payload or the link that justifies the ticket goes.
• Assignees: a collection of usernames. The Labels collection adds a Label and an Assignee at creation time.

Posts a comment under an existing issue. Nothing else moves: the issue keeps its state, its labels and its assignees.

• Issue Number: a number, not a title. Take it from the step that created or read the issue rather than typing it by hand.
• Body: the text of the comment, often a result the workflow has just computed.

Updates a ticket that is already open. Everything changeable sits in the Edit Fields collection, and you add only the fields you actually want to touch.

• Issue Number: the ticket to modify.
• State: open or closed, paired with State Reason, which takes completed, not_planned or reopened.
• Labels, Assignees, Title, Body: the rest of the collection, for a re-routing or a rewrite.

Looks up one issue and its data, with no effect on the repository. It is the read step a workflow puts in front of a decision: look at the state, look at the labels, then choose the branch.

• Issue Number: the number of the ticket to read.

Locks the conversation on an issue, which stops the thread from collecting new comments.

• Issue Number: the ticket to lock.
• Lock Reason: off-topic, too heated, resolved or spam. The reason travels with the lock, which saves writing a closing comment to explain it.

Every repository of an organization comes back as its own item, which is what makes a loop possible over an account nobody wants to list by hand.

• Return All: on, n8n follows the pages of the API until the organization is fully listed; off, it stops at Limit.
• Limit: the maximum number of repositories returned when Return All stays off.

Returns the people who belong to an organization, one item per member. Same pagination switch as the repository listing, pointed at a very different question: who has access.

• Return All: left off, n8n returns up to Limit members and stops there; turned on, it walks the whole roster.

Creates a release on a tag. It goes out published right away, or it waits as a draft while someone reads the notes over and decides if it is ready.

• Tag: the tag of the release, the single required field.
• Name and Body, in Additional Fields: the title of the release and the notes that go with it.
• Draft keeps the release unpublished, Prerelease marks it as not production ready.
• Target Commitish: the branch or commit SHA the tag is created from. Unused when the tag already exists, and left empty it falls back to the default branch, usually master.

Deletes one release, identified by its ID. There is nothing else to fill in, which also makes it the operation to double check before you activate the workflow.

• Release ID: the identifier of the release, not its tag and not its name. It comes from a listing step such as Get Many.

Fetches a single release and returns its data, changing nothing along the way. This is the step that gives a workflow the name and the notes of a release when all it received was an identifier.

• Release ID: the release to read, handed over by a Get Many step or by the operation that created it a few nodes earlier.

Brings back the releases of a repository. Useful when a workflow needs the history rather than the latest version.

• Return All: on, n8n pages through the whole release history; off, it stops at Limit.
• Limit: how many releases come back when Return All is off.

Changes a release that already exists, whether that means its notes, its name, its tag or its status.

• Release ID: which release to update.
• Draft: set to false, the release becomes published, which is how a two step release process ends.
• Body, Name, Tag Name, Prerelease and Target Commitish: the rest of the Additional Fields.

No parameter to fill in here. The operation hands back the data GitHub holds about a single repository, which makes it a cheap opening step: a workflow that is about to write files or open tickets can read the repository first and stop early if the answer is not what it expected.

Pulls the issues of a repository with the same filters you would reach for in the GitHub issue list.

• State: open, closed or all.
• Labels: several labels at once, separated by a comma.
• Updated Since: keeps only the issues updated at or after that moment.
• Assignee, Creator, Mentioned: narrow down by person.
• Sort and Direction: created, updated or comments, ascending or descending.
• Return All: off, the run stops at Limit.

When GitHub detects a license in the repository, this operation gives back the contents of that file. It takes no parameter, so it slots straight after a listing step and answers repository after repository. Nothing detected means nothing to read, and that silence is a result in itself.

Reads the community profile of a repository: metrics, health score, description, license and the rest of what GitHub measures there. No parameter to set, so the cost of adding it to a workflow is close to zero.

A review workflow that runs on a schedule rather than on an event starts here, with the pull requests of a repository brought back as items.

• State: open, closed or all.
• Sort: created, updated, popularity by number of comments, or long-running, which keeps only pull requests open for more than a month with activity in the past month.
• Limit: capped at 100, the maximum the API accepts for this list.

This one gives the top 10 content paths of a repository over the last 14 days. No filter, no date range: the window is fixed, so a longer view only exists if the workflow stores each run somewhere.

Same fixed window, different question: the top 10 referring domains of a repository over the last 14 days, in other words where its visitors came from. No parameter here either, and the same consequence, history is yours to keep.

Adds a review to an open pull request, with a verdict attached that a plain comment cannot carry.

• PR Number: the number of the pull request to review, typed in or read from an earlier node with an expression, written {{ $json.field }}.
• Event: the verdict, approve, requestChanges, comment or pending; pending leaves the review unsubmitted.
• Body: the review text, required by GitHub when the Event is Request Change or Comment.
• Commit ID, in Additional Fields: the SHA of the commit to review when it is not the latest.

Returns one review, the one whose identifier the node receives, on the pull request you name.

• PR Number: the pull request that holds the review; both values are required, so the pair travels together through the workflow.
• Review ID: the identifier of the review to fetch, usually kept from the node that created it.

Every review left on one pull request comes back, one item per review.

• PR Number: the pull request whose review history the node walks through.
• Return All: on, n8n follows the pages of the GitHub API until the last review; off, it stops at the number set in Limit.
• Limit: the maximum number of reviews to bring back while Return All stays off.

Only the text of an existing review changes here: the node exposes Body and nothing else to edit.

• PR Number: the pull request the review sits on.
• Review ID: the review to rewrite, the same identifier used to read it back.
• Body: the new text, which replaces what was posted before.

The repositories of the user come out as a list, one item each. No identifier is asked for in the node: only the pagination pair is on screen.

• Return All: on, the node keeps asking GitHub for the next page until every repository is out; off, it stops early.
• Limit: how many repositories to bring back while Return All is off.

Issues assigned to the user land in the workflow, and the Filters collection trims the pile before it ever reaches the next node.

• State: open, closed or all.
• Labels: one or several labels separated by commas, to keep only the issues carrying them.
• Updated Since: a date and time; only issues updated at or after it come through.
• Sort and Direction: order by created, updated or comments, ascending or descending.
• Mentioned: keeps only the issues where a given user was mentioned.

Sends an organization invitation to an email address, so a new teammate lands in the right place without anyone opening the members page.

• Organization: the GitHub organization the person is invited to.
• Email: the address of the invited person, in the form the field shows as a placeholder, name@email.com.

Switches one repository workflow off. It stays out of service until the Enable operation puts it back. Watch the word here: this is a workflow of the GitHub repository, not the n8n workflow around it.

• Workflow: the one to switch off, chosen in the field of the same name.

A dispatch event starts the repository workflow on demand, and n8n hands back control straight away: the execution does not sit and wait for the job to end.

• Workflow: the one to dispatch.
• Ref: the git reference the run uses, a branch or a tag name, which is how the same workflow goes out on a test branch or on a released tag.
• Inputs: a JSON object carrying the input parameters the workflow expects.

The launch is the same as Dispatch, what follows is not: the execution pauses and waits for a webhook, a URL called from the outside, before the next node runs.

• Workflow: the one to dispatch.
• Ref: the branch or tag name the run starts from.
• Inputs: a JSON object read by the run, handy to pass a version number or a target.

Enabling puts a parked workflow back to work: its own triggers fire again as soon as the call goes through.

• Workflow: the one to bring back, selected the same way as in Disable.

The node reads one workflow back from the repository and returns it as a single item, which is the quickest way to confirm that the identifier at hand points where you think it does.

• Workflow: the one to read.

GitHub reports the usage recorded for one workflow, which is the figure to watch when a repository consumes more than the team expected.

• Workflow: the one whose usage the node asks for.

Nothing to fill in here: the operation takes no parameter at all and returns the workflows as items, one per workflow, ready to loop over in the next node. It is the entry point when the identifiers are not known in advance.