Resources · Make integration

GitHub Make integrationAutomate GitHub with Make.

Your repositories already tell you what changed. Make can act on it for you. The GitHub Make integration gives you 12 triggers, 22 actions and 9 searches. This guide is for people who know GitHub but are new to Make: connect, build, test, switch on.

Verified Trustpilot reviews · AI, automation & growth agency

What you can automate

What can the GitHub Make integration do for you?

The GitHub Make integration links your GitHub account to Make, a no-code tool where you build a scenario (the automation itself) out of modules (one brick each: a trigger, an action or a search). Something happens in a repository, and Make does the follow-up work you would otherwise do by hand.

A support inbox that sorts itself. Customers report bugs as issues. Watch Issues picks each one up, Add Labels tags it and Add Assignees hands it to whoever is on duty. Nobody has to open GitHub just to triage.

Release notes that travel. Watch Releases picks up each new release on its next check, and Get a Release pulls its details, so another app in the scenario can post them to your team chat or your changelog sheet.

A clear view of outside interest. Watch Forks lists every new fork of an open-source project. Paired with Get a User, it tells you who is building on your code.

Keep the limits in mind. All 12 triggers are scheduled: Make checks GitHub on the scenario's schedule, it is never notified the second something happens. There is also no module to open or merge a pull request, create a branch or push a commit. For anything outside the list, the Execute a GraphQL Query module sends GitHub a query you write yourself, provided you know its language, GraphQL.

GitHub also has a node in n8n. If you are weighing the two tools, read the GitHub n8n integration page and our n8n vs Make comparison. New to the editor? The Make training starts from zero.

Connect

How do you connect GitHub to Make?

  1. 01

    Generate a token in GitHub

    Make signs in with an access token. In GitHub, click your profile picture, then Settings, then Developer settings. Under personal access tokens, pick Fine-grained tokens or Tokens (classic) and click Generate new token.

  2. 02

    Copy it before leaving the page

    Fill in the details GitHub asks for, click Generate token and copy the token shown on screen right away. That string is what Make will use to act on your account.

  3. 03

    Create the connection in Make

    Add any GitHub module to your scenario and click Create a connection. A connection is your GitHub account linked to Make once and reused by every GitHub module. Give it a name in Connection name if you like, then paste the token.

First scenario

Your first scenario: reply to every new issue

GoalWhen an issue appears in GitHub, Make posts a comment on it so the reporter knows it was seen.

  1. 01

    Create the scenario

    On the Scenarios page, create a new scenario and click the big + to add the first module. The first module decides when everything else runs.

  2. 02

    Add Watch Issues

    Search for GitHub, pick Watch Issues and click Create a connection with the token you copied. Then fill the fields; once connected, Make lists what it can read on your account.

  3. 03

    Add Create a Comment

    Click the + on the right of the trigger and pick Create a Comment. Map the issue from the first module and write your message, for example a thank-you with the issue title in it.

  4. 04

    Test with Run once

    Open a test issue in GitHub, then click Run once. Make runs the scenario one time and shows the bundle (one item passed between modules, here one issue) each module received.

  5. 05

    Schedule and switch it on

    Click the clock on the first module. A new scenario runs every 15 minutes by default; the Free plan cannot go below that. Switch the scenario on and it keeps checking without you.

Triggers

What can start a GitHub scenario?

12 modules start a scenario when something happens in GitHub. A scheduled trigger is checked by Make on the scenario's schedule; an instant one is called by GitHub as soon as it happens.

GitHub1Watch Branches

Watch Branches

Scheduled trigger

In MakeTriggers when a new branch is created.

Watch Branches spots each branch that shows up in GitHub and hands it to the next module as a bundle. It is a simple way to know that work has started on something, without asking.

How it fires
scheduled. Make checks GitHub on the scenario's schedule, so a new branch is picked up on the next check, not the moment it is pushed.
When to use it
your team names branches after tickets, and you want the matching task in your project tool moved to "in progress" once its branch shows up.
Watch out
it reacts to creation only. A branch that gets deleted or merged later does not start the scenario again.
GitHub2Watch Commit Comments

Watch Commit Comments

Scheduled trigger

In MakeTriggers when a new comment on a commit is created.

Watch Commit Comments catches remarks left directly on a commit, the kind that often gets lost because nobody gets pinged about it. Each new comment becomes one bundle.

How it fires
scheduled. Make asks GitHub for new comments each time the scenario runs on its schedule.
When to use it
a lead reviews commits after the fact and leaves notes there; you want each note copied to the author's chat or logged in a review sheet.
Watch out
this covers comments on commits only. Discussion on issues and pull requests needs a different module, such as Watch Issues or Search Comments.
GitHub3Watch Commits

Watch Commits

Scheduled trigger

In MakeTriggers when a new commit is created.

Watch Commits returns every new commit it finds since the last check, one bundle per commit. Think of it as a feed of code changes that other apps can read.

How it fires
scheduled. Commits pile up between two checks and arrive together when the scenario runs.
When to use it
a non-technical manager wants a plain list of what shipped, written into a spreadsheet row by row, without having to open GitHub.
Watch out
a busy repository can produce many commits between two runs, and each bundle the next modules process counts as an operation (one module run on one bundle) on your Make plan.
GitHub4Watch Forks

Watch Forks

Scheduled trigger

In MakeTriggers when a new fork is created.

Watch Forks tells you when someone copies a repository into their own account. For an open-source project, it is one of the clearest signals that people plan to build on the code.

How it fires
scheduled. Make looks for new forks on each run of the scenario.
When to use it
you maintain a public library and want each new fork logged with the owner's profile, fetched by Get a User, to see which companies are testing it.
Watch out
a fork is not a contribution. Many forks never change a line, so treat the list as interest, not activity.
GitHub5Watch Gists

Watch Gists

Scheduled trigger

In MakeTriggers when a gist is created or updated.

Watch Gists follows the small snippets and notes you keep as gists, and sends one bundle for each gist that is new or has been edited.

How it fires
scheduled. Make checks your gists when the scenario runs.
When to use it
you keep reusable scripts or checklists as gists and want a copy of each version saved to a notes app or a shared drive.
Watch out
edits count too. Fix a typo in an old gist and it comes through again, so plan for the same gist appearing more than once, for example by updating a record instead of adding a new one.
GitHub6Watch Issues

Watch Issues

Scheduled trigger

In MakeTriggers when an issue is created or updated.

Watch Issues is the trigger most GitHub scenarios start with. It sends a bundle for each issue that is opened, and also for each issue that changes.

How it fires
scheduled. Make checks for new and changed issues on the scenario's schedule, every 15 minutes by default.
When to use it
bug reports from customers should land in your helpdesk or your team chat without anyone copying them over.
Watch out
since updates fire it too, a scenario that edits the same issue (a label, a comment, a new assignee) can pick that issue up again on the next run. Add a filter so you only handle what you mean to.
GitHub7Watch Labels

Watch Labels

Scheduled trigger

In MakeTriggers when a new label is created.

Watch Labels reports each new label added to GitHub. It sounds minor, yet labels are often how a team encodes priority, customer or product area.

How it fires
scheduled. New labels are collected at each run of the scenario.
When to use it
you mirror GitHub labels in another tool, such as a tag list in your project board, and want new ones added there automatically so both stay aligned.
Watch out
it sees labels being created, not labels being put on an issue. To react when an issue gets tagged, start from Watch Issues instead.
GitHub8Watch Milestones

Watch Milestones

Scheduled trigger

In MakeTriggers when a milestone is created or updated.

Watch Milestones follows the milestones that group issues into a version or a sprint. A bundle arrives when one is created and again when one is updated.

How it fires
scheduled. Make looks at milestones on each scheduled run.
When to use it
a product manager plans releases in GitHub milestones and wants the roadmap in another tool to follow them, dates and titles included.
Watch out
closing a milestone is an update, so it comes through as well. Check its state in a filter if the next step should only run for open ones.
GitHub9Watch Organizations

Watch Organizations

Scheduled trigger

In MakeTriggers when a new organization is created.

Watch Organizations sends a bundle when a new GitHub organization is created. It sits at the account level, above single repositories.

How it fires
scheduled. Make checks for new organizations on the scenario's schedule.
When to use it
your company spins up a separate organization for each client or each product, and IT wants each one recorded in an inventory sheet as it appears.
Watch out
Make only sees what the token can see. If the account behind the connection has no access to an organization, that organization will not show up here.
GitHub10Watch Pull Requests

Watch Pull Requests

Scheduled trigger

In MakeTriggers when a pull request is created or updated.

Watch Pull Requests brings each pull request into your scenario, whether it was just opened or has changed since the last check.

How it fires
scheduled. Make collects new and updated pull requests every time the scenario runs.
When to use it
reviewers keep missing requests in their inbox, so you want each one posted in the team channel with its title and author.
Watch out
a pull request gets updated a lot during review. If you only want one message per request, filter on its creation or store the ones you already posted.
GitHub11Watch Releases

Watch Releases

Scheduled trigger

In MakeTriggers when a new release is created.

Watch Releases fires on each new release of a repository. For anyone outside the dev team, a release is the moment that matters: something new is out.

How it fires
scheduled. The release is picked up on the next scheduled run, not instantly.
When to use it
sales and support need to hear about each version, so the release notes go straight to an email or a chat message they already read.
Watch out
editing a release afterwards does not start the scenario again, since this trigger watches for new ones only.
GitHub12Watch Repositories

Watch Repositories

Scheduled trigger

In MakeTriggers when a new repository is created.

Watch Repositories reports every repository created on the account behind the connection, one bundle each.

How it fires
scheduled. Make checks for new repositories on the scenario's schedule.
When to use it
a tech lead wants each new project to get the same setup routine, such as a starter issue opened with Create an Issue that lists the steps to follow.
Watch out
any repository counts, including quick experiments. A filter on the name keeps throwaway projects out of the routine.
Modules

What else can Make do in GitHub?

GitHub gives you 31 modules. For each one: what it does for you, when to reach for it, and what to watch out for.

GitHub1

Add Assignees

Action

In MakeAdds assignees to an issue or pull request.

Add Assignees puts one or more people in charge of an issue or a pull request, so the work has a clear owner.

When to use it
a bug labeled "billing" should go straight to the person who owns billing code.
Watch out
it adds people, it does not replace the current ones. Use Delete Assignees first if you want a clean handover.
GitHub2

Add Labels

Action

In MakeAdds labels to an issue or pull request.

With Add Labels, Make tags an issue or a pull request the way your team would by hand.

When to use it
issues reported through a form should arrive already marked "from customer" so they stand out in the list.
Watch out
labeling an issue updates it, which Watch Issues will notice on its next run.
GitHub3

Create a Comment

Action

In MakeCreates a new comment.

This module writes a new comment in GitHub, under the name of the account behind the connection.

When to use it
you want to tell a reporter their bug is logged, or post the outcome of a check run elsewhere.
Watch out
the comment shows your account as author, so consider a dedicated bot account for the connection.
GitHub4

Create an Issue

Action

In MakeCreates a new issue.

Create an Issue opens a fresh issue from data coming out of another app: a form, an email, an alert.

When to use it
your helpdesk flags a ticket as a bug, and developers should see it in GitHub without anyone retyping it.
Watch out
without a check first, the same ticket can become two issues. Search Issues helps you spot duplicates.
GitHub5

Delete a Comment

Action

In MakeRemoves an existing comment.

Delete a Comment removes a comment that already exists in GitHub.

When to use it
a scenario posts a temporary status comment and should clean it up once the job is done.
Watch out
a deleted comment cannot be brought back from Make, so test it with Run once on a throwaway issue first.
GitHub6

Delete a Label

Action

In MakeRemoves a label from an issue.

Delete a Label takes one label off an issue. The label itself stays available in the repository.

When to use it
once a fix is confirmed, the "needs triage" tag should disappear so the backlog stays readable.
Watch out
it works on issues; for anything else, check the result on a test run.
GitHub7

Delete an Issue

Action

In MakeRemoves an existing issue.

Delete an Issue removes an issue for good, which goes further than closing it.

When to use it
spam issues on a public repository, once a filter has confirmed they are junk.
Watch out
there is no undo. If you only want the issue out of sight, Update an Issue to close it is the safer move.
GitHub8

Delete Assignees

Action

In MakeRemoves assignees from an issue or pull request.

Delete Assignees takes people off an issue or a pull request without touching the rest of it.

When to use it
someone leaves the project and their open items should go back into the shared pool.
Watch out
pair it with Add Assignees when you reassign, otherwise the item stays ownerless.
GitHub9

Execute a GraphQL Query

Action

In MakePerforms an arbitrary authorized GraphQl query.

Execute a GraphQL Query sends GitHub a query you write yourself in GraphQL, GitHub's query language, with the access of your connection. It covers what the other modules do not.

When to use it
you need data no Get or Search module returns, and someone on the team can write GraphQL.
Watch out
this is the one technical module here; everything else needs no query language.
GitHub10

Get a Branch

Action

In MakeRetrieves an existing branch.

Get a Branch fetches the details of one branch you already know about.

When to use it
a message mentions a branch name and you want its details before deciding what the scenario does next.
Watch out
it needs one specific branch. To browse several, use Search Branches.
GitHub11

Get a Comment

Action

In MakeRetrieves an existing comment.

Get a Comment reads a single existing comment in full.

When to use it
an earlier module only gave you a reference to a comment, and the next step needs its text.
Watch out
if the comment was deleted in the meantime, the module has nothing to return and the run can stop there.
GitHub12

Get a Gist

Action

In MakeRetrieves an existing gist.

Get a Gist loads one gist so its content can be reused further down the scenario.

When to use it
you store a message template in a gist and want the latest version each time the scenario sends it.
Watch out
the gist has to be visible to the account behind the connection. A colleague's secret gist will not come back.
GitHub13

Get a Milestone

Action

In MakeRetrieves an existing milestone.

Get a Milestone returns the current details of one milestone.

When to use it
before posting a sprint update, you want the milestone's latest title and state rather than stale data.
Watch out
it reads one milestone. Search Milestones is the one for listing them.
GitHub14

Get an Assignee

Action

In MakeRetrieves an existing assignee.

Get an Assignee looks up one assignee, which is handy to confirm a person can take work in that place.

When to use it
a routing rule names someone, and you want to check them before Add Assignees runs.
Watch out
a typo in the username leads to an error, not to a silent skip.
GitHub15

Get an Issue

Action

In MakeRetrieves an existing issue.

Get an Issue pulls the full, current version of one issue.

When to use it
a customer asks about a bug in your helpdesk and the reply should quote the issue's real status.
Watch out
it reads, it does not change anything. To edit, chain Update an Issue after it.
GitHub16

Get an Organization

Action

In MakeRetrieves an existing organization.

Get an Organization returns the details of one GitHub organization.

When to use it
Watch Organizations flagged a new one, and your inventory sheet needs more than its name.
Watch out
what comes back depends on what the token is allowed to see.
GitHub17

Get a Pull Request

Action

In MakeRetrieves an existing pull request.

Get a Pull Request reads one pull request as it stands right now.

When to use it
a deployment tool asks whether a change is ready, and the answer should come from GitHub, not from memory.
Watch out
between two runs a pull request can change a lot, so fetch it at the moment you need it.
GitHub18

Get a Release

Action

In MakeRetrieves an existing release.

Get a Release loads one release with its details, including what you wrote about it.

When to use it
right after Watch Releases, to send complete release notes to a customer newsletter tool.
Watch out
a draft written in a rush will be sent as is, so review release texts in GitHub first.
GitHub19

Get a Repository

Action

In MakeRetrieves an existing repository.

Get a Repository returns the full record of one repository you already know. Handy when an earlier module only gave you its name.

When to use it
each new project should get a row in your dashboard, filled with its details rather than just its name.
Watch out
private repositories only come back if the token has access to them.
GitHub20

Get a User

Action

In MakeRetrieves an existing user.

Get a User turns a GitHub username into a profile you can work with.

When to use it
Watch Forks gave you a username and you want to know who is behind it before reaching out.
Watch out
people fill their profile as they like; many fields can be empty, so map them with care.
GitHub21

Update a Comment

Action

In MakeUpdates an existing comment.

Update a Comment rewrites an existing comment on an issue or a pull request.

When to use it
a scenario posts "checking..." and later swaps it for the final result, so the thread stays short.
Watch out
keep the comment's reference from the step that created it, or you will have to search for it again.
GitHub22

Update an Issue

Action

In MakeUpdates an existing issue.

Update an Issue changes an issue that already exists, the same way you would edit it in GitHub.

When to use it
the helpdesk ticket is solved, so the linked issue should be closed without a developer stepping in.
Watch out
the change counts as an update for Watch Issues, which can start your own scenario again.
GitHub23

Search Assignees

Search

In MakeSearches for assignees or lists them all.

Search Assignees lists the people who can be assigned work, or finds the ones matching your search.

When to use it
you want to spread new issues across the team instead of hard-coding one name.
Watch out
like every search, it can return zero, one or many bundles, and each later module runs once per bundle.
GitHub24

Search Branches

Search

In MakeSearches for branches or lists them all.

Search Branches returns the branches that match what you look for, or all of them.

When to use it
you want a list of branches that were never cleaned up, sent to the lead for review.
Watch out
on a large repository the list can be long, and every item costs operations further down.
GitHub25

Search Comments

Search

In MakeSearches for comments or lists them all.

Search Comments digs through comments to find the ones you need.

When to use it
before posting an automatic reply, check that the scenario has not already replied on that thread.
Watch out
an empty result is normal, so plan what the scenario should do when nothing matches.
GitHub26

Search Gists

Search

In MakeSearches for gists or lists them all.

Search Gists finds gists or lists all of them from the connected account.

When to use it
you are moving your snippets to a knowledge base and want every gist exported in one pass.
Watch out
each gist found is a separate bundle, and so a separate operation in the next module.
GitHub27

Search Issues

Search

In MakeSearches for issues or lists them all.

Search Issues is the lookup to run before creating anything, to see whether the issue already exists.

When to use it
a monitoring alert fires again and should add a comment to the open issue, not open a second one.
Watch out
no result does not mean an error. Add a filter so the next step only runs when something was actually found.
GitHub28

Search Milestones

Search

In MakeSearches for milestones or lists them all.

Search Milestones lists milestones or narrows them down to the ones you want.

When to use it
a planning sheet should show every milestone of a project, not only the one just updated.
Watch out
closed milestones may show up too, so filter on state if the list is for current work.
GitHub29

Search Organization Members

Search

In MakeSearches for organization members or lists them all.

Search Organization Members returns the people in an organization, all of them or those matching your search.

When to use it
an access review needs the current member list compared with your HR tool.
Watch out
the list reflects what the token can see, which may be less than an owner sees.
GitHub30

Search Pull Requests

Search

In MakeSearches for pull requests or lists them all.

Search Pull Requests brings back a batch of pull requests in one go.

When to use it
you want a digest of every request still waiting for review, sent to the channel where reviewers hang out.
Watch out
to send one message and not one per request, add an aggregator after it.
GitHub31

Search Releases

Search

In MakeSearches for releases or lists them all.

Search Releases lists the releases of a repository, or the ones matching your search.

When to use it
you are building a version history page in another tool and need past releases, not just the next one.
Watch out
run it once for the backlog, then let Watch Releases handle new ones, so you do not import the same release twice.
Need help

Need help automating GitHub with Make?

A person reads every message.

FAQ

GitHub and Make: common questions

01Is the GitHub Make integration free?
Yes. GitHub is a standard app, so it works on Make's Free plan. That plan has limits: 2 active scenarios, at least 15 minutes between two scheduled runs, 5 minutes per execution, files up to 5 MB and 512 MB of data transfer. Paid plans (Core, Pro, Teams, Enterprise) bring the interval down to 1 minute, remove the cap on active scenarios and allow 40 minutes per run. Usage is counted in operations each month, one per module run on one bundle. On the GitHub side, you need an account; check GitHub's own pricing page for what your plan covers.
02What does it take to connect GitHub to Make?
Two things: an active GitHub account and an access token. You create the token in GitHub under Settings, then Developer settings, then personal access tokens, where you can choose fine-grained tokens or classic ones. Click Generate new token, fill in the details, generate it and copy it. In Make, add a GitHub module, click Create a connection, optionally name it, and paste the token. The connection is then reused by every GitHub module in your scenarios, so you only do this once.
03Do GitHub triggers in Make fire in real time?
No. All 12 GitHub triggers in Make are scheduled. Make asks GitHub for anything new each time the scenario runs, which is every 15 minutes by default. On a paid plan you can shorten that interval to 1 minute, while the Free plan stays at 15 minutes minimum. The clock badge on the module shows it is scheduled. If a few minutes of delay is a problem for your process, keep that in mind before building around these triggers.
04What if the GitHub module you need is missing from Make?
It depends on what is missing. GitHub has no Make an API Call module, the catch-all module other apps offer for doing things by hand. Its stand-in here is Execute a GraphQL Query: you write a query yourself in GraphQL, the query language GitHub understands, and Make sends it with your connection's access. If nobody on your team can write that kind of query, look for another app that can do the job in the same scenario, or ask the team for help. One more thing: the official documentation for this app is marked as AI-generated, so test each module with Run once before relying on it.
05Make or n8n for GitHub: which one fits?
It depends on who builds and maintains the automation. GitHub also exists as a node in n8n, so both tools are an option. On the Make side you get 43 GitHub modules, including 12 triggers, all of them scheduled. To decide, list the modules you need and check they exist, ask who will keep the scenario running six months from now, and see whether a delay of a few minutes hurts your process. The rest comes down to which tool your team is comfortable with, not a ranking between the two.