> ## Documentation Index > Fetch the complete documentation index at: https://docs.frontic.com/llms.txt > Use this file to discover all available pages before exploring further. # GitHub Integration GitHub integration is **optional but unlocks production shipping**. [Studio](https://docs.frontic.com/studio/frontic-studio.md) works end-to-end without GitHub - scaffold from a framework template, build with the chat, iterate against the live preview, and share via the preview URL or a workspace download. Connect GitHub when you're ready to push work to a real repo, open pull requests, and run it through your team's review flow. Once connected, Studio builds on **real Git branches in real repositories**. File changes the Studio chat makes are committed to a branch on your GitHub repository, and you open a pull request through GitHub's normal flow. No custom review tool, no "AI commits" marker - ordinary Git that happens to have been authored through a chat interface. This page covers the full GitHub-side flow: installing the Frontic GitHub App, committing from the Changes panel, opening a PR, and coordinating PRs with [Releases](https://docs.frontic.com/releases/overview.md) when a change touches both frontend code and stack config. ## Connecting GitHub GitHub integration uses a **GitHub App installed on your GitHub organization** (or personal account). It's an organization-wide install: a GitHub admin sets it up once, and every teammate on the Frontic project can use Git features in Studio - push, branch, open PRs - with no individual GitHub setup of their own. You can start the install from either of two places: > [card] From Studio Settings > > Open [Studio Settings](https://docs.frontic.com/studio/settings.md) (the gear icon in the Board header), open the GitHub section, and click > **Install GitHub App**. Useful when you want to set up GitHub up front, > before any job. > [card] From a Create Job dialog > > Open Create Job, expand **Source configuration**, and switch the source to **GitHub Repository**. Install the GitHub App inline; the dialog returns with repository mode pre-configured, ready to pick the repo and branch. Either path opens GitHub's App installation flow, where you pick the organization to install on and choose which repositories the App can access. After you confirm, the installation is saved at the project level and every subsequent job can target any repository you granted access to. You can connect additional GitHub organizations at any time - each gets its own installation, and all active installations are listed in **Studio Settings → GitHub**. > [!NOTE] > > Installing on an organization may require approval from a GitHub org admin if your organization restricts third-party App installs. If you don't see your org in the picker, ask an admin to install the Frontic GitHub App for you. This approval applies per organization - when you add a second or third org, a GitHub admin for that org needs to approve it too. **studio/settings-github** Studio Settings - GitHub tab showing two connected GitHub organizations, each with its own Repository Access list, Manage Repositories button, and Uninstall & Disconnect action, plus an Add GitHub Organization button at the bottom ![Studio Settings - GitHub tab showing two connected GitHub organizations, each with its own Repository Access list, Manage Repositories button, and Uninstall & Disconnect action, plus an Add GitHub Organization button at the bottom](https://mintcdn.com/frontic/h2E4fWn8KR2uQpFy/images/studio/settings-github-light.png?fit=max\&auto=format\&n=h2E4fWn8KR2uQpFy\&q=85\&s=e6f2deed32373b8ff1243a2cc5addd62) Once the App is installed, Create Job uses your connection to pre-fill the source. The dialog opens with **Source configuration** collapsed - its summary line shows the current selection (a template name when no GitHub is connected, or the repository's full name when one is). When you've used a repository before, that one comes back pre-selected, and the base branch field is pre-filled with the last branch you targeted. With a fresh install and a single accessible repo, that repo is picked silently. Multiple accessible repos with no history is the only case that opens with the section expanded so you can choose. **studio/github/create-job-repository** Create Job dialog showing the Name field and an expanded Source configuration section with a Template / GitHub Repository toggle set to GitHub Repository, the chosen repo with a Change action, and a Base Branch dropdown set to main ![Create Job dialog showing the Name field and an expanded Source configuration section with a Template / GitHub Repository toggle set to GitHub Repository, the chosen repo with a Change action, and a Base Branch dropdown set to main](https://mintcdn.com/frontic/rLUrMB73G0Gw9fyZ/images/studio/github/create-job-repository-light.png?fit=max\&auto=format\&n=rLUrMB73G0Gw9fyZ\&q=85\&s=d33771e302d053031f649b987dca341f) Create Job dialog with Source configuration expanded, GitHub Repository selected, the chosen repo, and the base branch selector ### Repository access After the App is installed, each connected organization shows its own **Repository Access** panel in Studio Settings listing the repositories Studio can see for that org. The list is paginated - load more if you have many repos. If you have multiple organizations connected, each appears as its own installation card with its own Repository Access panel. To change which repositories the App can access for an org, click **Manage Repositories** on that org's installation card. That redirects you to the GitHub App's installation settings on GitHub, where you can add or remove repositories. Save there, and GitHub redirects you back to Studio with the new list. Changes apply immediately for everyone on the project. Use this when: * A new repository was created after the App was installed and isn't in the picker yet * You want to scope Studio to a narrower set of repos than what's currently granted * You're auditing what Studio has access to ### What Studio does with the connection When a job runs against a GitHub repository: * The workspace **clones the repo** when the job starts * The Studio chat creates **a new branch** off the base branch you pick * Every file edit is a change on that branch * Clicking Commit in the Changes panel commits on the branch and pushes to GitHub in one step * Pull requests target the base branch Everything is standard Git. Commits are authored by the GitHub App, not by the teammate who ran the job - so don't use the commit author field for attribution. ### Multi-repository projects Each Studio job picks its own repository and base branch at creation - there's no per-project default repository to override. If your team maintains multiple frontends (web storefront, mobile app, admin surface) against the same Frontic project, each can live in its own repo - including repos across different GitHub organizations if you have multiple orgs connected - and jobs target whichever one you're working on. ### Revoking access Two ways: * **From Frontic** - Go to **Studio Settings → GitHub** and click **Uninstall & Disconnect** on the installation you want to remove. Each connected organization is disconnected independently - removing one does not affect other connected organizations. Existing jobs that target that org's repositories finish; no new jobs can be created against those repositories until the App is reinstalled. * **From GitHub** - in your organization's **Settings → GitHub Apps → Frontic Studio**, click **Uninstall**. GitHub enforces immediately. Neither deletes already-committed work - that's in your Git history and belongs to you. ## Create a repository from a job Not every job starts from GitHub. When you scaffold a job from a [framework template](https://docs.frontic.com/studio/frontic-studio.md) (Nuxt or Next.js), the [workspace](https://docs.frontic.com/studio/workspace.md) has no repository connected. **Create Repository** enables you to create a new GitHub repository from a template job in one step. The action only appears while the job has **no repository connected**. You'll find it in two places: the workspace panel toolbar, and the [Changes panel](https://docs.frontic.com/studio/workspace.md#the-changes-panel), which shows it in place of the file list until a repository exists. Both open the same dialog. ### Before you start Two things must be in place: * **GitHub connected at the project level** - the Frontic GitHub App is installed (see [Connecting GitHub](#connecting-github)). * **At least one organization installation** - the org picker lists GitHub *organizations* only. Personal GitHub accounts aren't supported here. If your only installation is a personal account, connect an organization from **Studio Settings → GitHub** first. The dialog handles the gaps for you. If GitHub isn't connected at all, it shows an inline **Connect GitHub** prompt - the same install flow as [Studio Settings or Create Job](#connecting-github). If GitHub is connected but no organization is available, it links you to **Studio Settings → GitHub** to add one. ### Creating the repository **1. Open Create Repository** Click **Create Repository** in the workspace panel toolbar or in the Changes panel. **2. Pick the organization** Choose the GitHub organization to create the repository under. When only one organization is connected, it's pre-selected. **3. Name the repository** Enter a name - letters, numbers, hyphens, underscores, and dots, 1–100 characters. Add an optional description if you like. **4. Choose visibility** The repository is **private** by default. Flip the toggle to make it public. **5. Confirm** Studio creates the repository under the organization, pushes the current workspace as the initial commit, and connects it to the job. Once it's done, the job is a normal GitHub-backed job: the [Changes panel](https://docs.frontic.com/studio/workspace.md#the-changes-panel) is live, and the full [Commit](#commit) → push → [open a pull request](#open-a-pull-request) flow works exactly as it does for a job that started from an existing repository. > [!NOTE] > > The repository is created empty and your current workspace lands as the first commit on the default branch (`main`). There's no separate base branch to choose - this flow both creates the repo and pushes to it in one confirm. ## Commit Once Studio has made file changes you're happy with, commit them from the workspace. The [Workspace](https://docs.frontic.com/studio/workspace.md) page covers reviewing the diffs in detail; this section covers the commit mechanics. **1. Review the diffs** Before committing, open the Changes panel and read every file - not only the ones you expected. Agents sometimes touch imports, shared utilities, or generated files you didn't mention. Worth knowing what landed. **2. Review or write a commit message** Studio drafts a commit message from the diff as soon as the dialog opens. If you want to write your own commit message, just start typing - your text is kept and the suggestion is dropped. **3. Confirm the target branch** The dialog has a **Commit changes to** row that shows the branch the commit will land on - the workspace's feature branch by default. Click the row to expand it and switch to a different existing branch or create a new one (under the hood it's the standard branch selector with **Existing branch** and **Create new branch** options). Leave it collapsed when the default is right. **4. Click Commit** Studio commits on the branch and pushes to GitHub in one step. The first commit creates the branch on GitHub; later commits fast-forward it. The Changes panel shows the branch up to date with remote when it's done. ## Open a pull request When a commit moves the job onto a new branch - usually your first commit to the feature branch - the success notification offers **Create Pull Request**. It opens GitHub's compare page from the branch the job was on to the one you just committed to, with the pull request already drafted: * **Title** - the first line of your commit message. * **Description** - a short changelog Studio writes from the job's conversation and the committed changes: what changed and what it enables, in plain language, without file names or Git jargon. Both land in GitHub's own form, so edit or replace them, add the context your team needs (ticket links, screenshots, test notes), and create the PR as you normally would. If the description can't be written within a few seconds, the page opens with only the title filled in and you write the description yourself. Later commits to the same branch don't offer the action again; open the PR from GitHub if you skipped it. > [!TIP] > > Spend 30 seconds on the drafted description before you create the PR. It says *what* changed; add *why* it changed and *what to look at first*. A good description saves more review time than it takes to write. ## Merging and cleanup When the PR is approved and CI is green, merge it like any other PR. After merge: * The feature branch can be deleted (your team's usual branch cleanup applies) * The Studio job stays around - you can reopen it later for follow-up work in the same workspace * If the change involved workspace changes (new blocks, listings, pages), test the production deploy and then publish the version, as described below ## Coordinating with releases A PR is about code. [Release Control](https://docs.frontic.com/releases/overview.md) is about the API version your frontend reads. When a change involves both - which most meaningful changes do - the order matters: **1. Preview a version first** Preview a version in the admin app, so you test against a snapshot of the workspace that holds still. **2. Generate the Client SDK against the preview** Run `frontic generate preview`. The SDK carries the preview version's key. **3. Commit the SDK + frontend code** Commit the generated client files alongside the frontend code that uses them. Push the branch. **4. Open the PR** Mention in the description that the PR depends on a Frontic preview version. Reviewers need to know the PR relies on changes the public version doesn't have yet. **5. Deploy the PR to a preview deploy** Your deploy pipeline builds a preview deploy. Because the SDK in the branch carries the preview's version key, the preview deploy reads the Frontic preview version - so QA validates the full stack, not only the code. **6. Merge and test production** When QA passes, merge. Production deploys the new frontend with the same SDK, so it reads the preview version: the version you are about to publish. Test the production deploy. **7. Publish the version** Publish the preview version. It becomes the public version at once, so the app you tested is already live on it, with no redeploy. Publishing is irreversible. Previewing first and publishing last gives you a QA checkpoint where the frontend and the API version both hold still, so you're not chasing a moving target, and the switch to the new version happens in one step once the deployed app is right. For a worked example, see [Your First Feature](https://docs.frontic.com/essentials/your-first-feature.md). > [!NOTE] > > Preview - the next iteration of this flow pairs a [draft](https://docs.frontic.com/releases/overview.md#drafts) with the Studio job and the PR, so the draft, the frontend code, and the release that ships both move together. In preview today; expanding as it matures. ## Troubleshooting > [accordion] My repository isn't showing up in the picker > > The repository wasn't included in the App's repository access grant. > In **Studio Settings → GitHub**, click **Manage Repositories** to > open the GitHub App's installation settings, add the missing repo, > and save. The picker refreshes with the new list. > [accordion] The GitHub App installation didn't complete > > Most often this is an organization permissions issue: the org > requires admin approval for third-party App installs, and the > request is still pending. Ask a GitHub org admin to approve (or > install) the Frontic Studio App for the organization. If you > cancelled the install partway through, just click **Install GitHub > App** again. > [accordion] A teammate can't push to GitHub from Studio > > Once the App is installed on the org, every teammate on the Frontic > project gets Git access - no per-user GitHub setup is required. If > a teammate is blocked, check that the repository they're working on > is included in the App's repository access (see **Manage > Repositories**) and that they have the Frontic permissions to use > Studio in this project. > [accordion] Connecting a GitHub organization that's already connected to another Frontic team > > Supported. From the second Frontic team, go to **Studio Settings → GitHub** > and click **Install GitHub App**, then complete > the GitHub App authorization flow. When GitHub redirects back, > Frontic detects that the same installation is being attached to a > new Frontic team and finalises the connection. Both Frontic > teams can then target repositories under the same GitHub > organization independently - each has its own repository access > settings and its own job and workspace history. > > Note: this is distinct from connecting *multiple* GitHub organizations to a single Frontic project - use the **Add GitHub Organization** button in Studio Settings → GitHub for that. > [accordion] Create Repository fails saying the App can't create repositories in this organization > > The Frontic GitHub App installation for that organization doesn't have > permission to create repositories. Reconfigure the installation to > grant repository administration access - in **Studio Settings → > GitHub**, use **Manage Repositories** on that org's card to open its > GitHub App settings, then approve the added permission (a GitHub org > admin may need to do this). Once granted, reopen the dialog and try > again. > [accordion] I connected a second GitHub org but its repositories aren't showing in the picker > > The GitHub App installation for that org may not include the repositories you need. In **Studio Settings → GitHub**, find the installation card for the org you just added and click **Manage Repositories**. This opens the GitHub App's installation settings for that org, where you can add the missing repositories and save. The picker refreshes immediately. ## Related > [card] [Release Control](https://docs.frontic.com/releases/overview.md) > > How your workspace changes reach the public version. (Plus plan.) > [card] [Studio](https://docs.frontic.com/studio/frontic-studio.md) > > Where chat-driven changes happen before they hit the connected > repository. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.