Docs › Connections

GitHub

Connect the repository your website is built from. EOMA opens a pull request you review and merge — it never writes to your main branch.

#In 10 seconds

• EOMA installs an app on the repositories you choose, and works only inside those.
• Every change arrives as a pull request on its own branch named eoma/draft/…. Your main branch is never written to.
• Nothing reaches your visitors until you merge. That step stays with you, always.

#Before you start

• Your website must be built from a Git repository on GitHub. If your site is WordPress, connect that instead — see Integrations.
• You need permission to install an app on the repository. On a personal account that is you; on an organisation it is an owner, or someone an owner has approved.
• You must be the owner of the brand in EOMA, otherwise the row shows "Owner only".

#Steps

#1 — Press Connect and choose the repositories

Settings → Integrations → the Publishing — CMS & Sites group → the GitHub row.

┌─ Settings ─────────────────┬──────────────────────────────────┐
│  WORKSPACE                 │  Publishing — CMS & Sites        │
│    Plan & Usage            │    WordPress      [ Connect ]    │
│  ● Integrations   ← here   │    GitHub         [ Connect ] ←  │
└────────────────────────────┴──────────────────────────────────┘

Connect sends you to GitHub's own install screen. GitHub asks which account or organisation to install into, and then whether to grant all repositories or only select repositories. Choose only select repositories and pick the one your site is built from. This is the single most important decision on this page: it is the boundary of everything that follows.

#2 — Choose the repository and the branch

Back in EOMA the row shows Select repo. Pressing it opens Select Repository — the list of repositories you granted access to, and a Branch dropdown underneath.

The branch you pick is the base: the branch EOMA compares against and points its pull requests at. For most sites that is main, which is already selected for you. Press Save.

#3 — Approve a piece of work and choose GitHub

Connecting gives EOMA somewhere to go. It does not send anything by itself. The first pull request appears when you approve a finished draft on Actions and pick GitHub as the destination.

#What you'll see

#The GitHub row and its "Connect" button

In Publishing — CMS & Sites, second row. Non-owners see Owner only where the button is.

#GitHub's own install screen

Not part of EOMA. This is where repository access is granted, and it is the only place it can be changed later.

#"Select Repository" — the repo list and "Branch"

One line per repository you granted, showing its full name and its default branch. Below the selection, a Branch dropdown. At the bottom left, a link reading "Don't see your repo? Manage repository access on GitHub →".

#The row once a repository is chosen

The button is replaced by owner/repo · branch, with Change repo and Disconnect beside it. Change repo re-opens the same picker — you can move to a different repository without disconnecting and starting over.

#The pull request, on GitHub

Not in EOMA. A branch called eoma/draft/<id>, the changed files, and a pull request pointed at your base branch. EOMA also posts the link back onto the action, so you can open it from either side.

#Reading the numbers

What EOMA writes, exactly. This is the blast radius, and it is small on purpose:

If EOMA cannot do something within those lines, it stops and tells you. It has no second route.

"Don't see your repo?" The picker lists only what the app was granted. A repository missing from the list is not broken — it was outside the selection you made on GitHub. The link takes you to the page where you widen it. You do not need to disconnect first.

The branch list can be shorter than your real branch list. EOMA reads up to 100 branches. Your default branch is always at the top and always selectable, so a repository with hundreds of branches still works; a rarely-used branch may just not appear. If you need one that is missing, tell support.

Where the file lands. EOMA picks a path from the kind of work: a blog post goes to content/blog/<name>.md, a page to content/pages/<name>.md, your llms.txt to the root of the repository. Structured-data snippets go to content/schema/. If your repository is laid out differently, say so before the first publish and the paths can be set per brand — a pull request in the wrong folder is easy to close, but easier not to open.

"Opens a pull request in your repo — merging stays with you". The line you will see when you approve. The confirmation that follows spells out the same three facts: EOMA opens the pull request and writes nothing directly, you see the change line by line, nothing goes live until you merge.

Disconnecting removes the installation. Pressing Disconnect removes EOMA's app from your GitHub account as well as the connection inside EOMA. Branches and pull requests already opened stay where they are — they are yours. You can delete or merge them at your own pace.

#When it goes wrong

#Related

• Actions — where you approve the work that becomes a pull request
• Vercel — for a Vercel site that deploys from this same repository
• WordPress — the destination that publishes live instead