Maybe you switch between a personal account and a work account. Maybe your company uses GitHub Enterprise while you also contribute to open source projects. Or maybe you juggle several enterprise instances across different clients. Whatever the case, moving between accounts usually means dealing with annoying credential switches, SSH key conflicts, or separate clones of the same project.

GitButler removes a lot of that friction. With built-in GitHub integration, you can connect more than one GitHub account at the same time. This includes your regular GitHub account plus any number of GitHub Enterprise accounts. In this tutorial, we will walk through how to set that up, how to work comfortably across multiple accounts, and how to handle custom self hosted GitHub Enterprise servers that require extra Content Security Policy settings. By the end, you should feel confident connecting any GitHub identity you use, and moving between them without jumping through hoops.

It’s important to note, the credentials are local: they never leave your computer (see below). Each credential is encrypted and persists via the operative system’s native keychain tooling.

(Example: GitButler Credentials in the Mac OS Keychain)

The first place you will visit is the Integrations section of GitButler.

1. Open GitButler.
2. Click your profile image in the sidebar to open settings.
3. Select the Integrations tab.

You will see a set of supported forges, including GitHub. Next to GitHub is an Add account button. When you click that, GitButler shows three ways to authenticate.

Device Flow is the easiest option for a regular GitHub account. When you choose this method, GitButler gives you a short code. You open the GitHub activation page in your browser, enter the code, and approve the access request. Once approved, go back to GitButler and click Check status. If the connection succeeded, your GitHub username appears in the list of linked accounts.

This option is great if you simply want to hook up your personal GitHub account. You do not need to think about scopes, tokens, or permissions.

If you prefer to use a Personal Access Token, select the option in the Add account flow. This is helpful if you want tighter control over permissions or if your organization has policies around OAuth. When you paste in your token, GitButler checks that it has read access to repository metadata and read and write access to pull requests. If something is missing, creating or updating pull requests might fail, so it is worth making sure the token is configured correctly.

Note: GitButler is a tool to help the developer and acts on their behalf. Ensure you are following your company or organization’s policy with regard to Personal Access Tokens.

For GitHub Enterprise, select the GitHub Enterprise option. GitButler will ask for the base API URL of the enterprise server, plus a personal access token for that specific instance. The API URL often looks something like:

https://github.mycompany.com/api/v3

Once you enter the base URL and your token, click Connect. If the server is reachable and your token is valid, the enterprise account gets added right next to your other GitHub accounts.

The important thing to know is that GitButler does not limit you to one enterprise account. If you work with two or three different client hosted GitHub Enterprise servers, you can add each one separately. They all appear in the Integrations list.

Take note of the portion onCloud Service Providers (CSP) below as this will be necessary when connecting to an enterprise Github repository.

If you ever need to disconnect an account, click the Forget button next to the entry. You can safely remove and re add accounts whenever you want without breaking your repos or branches inside GitButler.

Once your accounts are connected, GitButler becomes a unified control center for all your GitHub and GitHub Enterprise projects. Here is what that looks like in daily use.

You can clone repositories from any connected account. If you have a personal open source project and a work project that lives under an enterprise domain, GitButler handles them side by side. You never need to manually tweak remotes or juggle SSH configs to make these repos coexist.

Creating Branches and Making Commits

Inside GitButler, work feels the same no matter which account the repository belongs to. You can create virtual branches, make snapshots, reorder commits, and manage your work exactly as you would with any other GitButler project.

GitButler keeps each repo isolated with its own remote and its own account identity. You do not need to switch accounts or toggle any settings to work on a project from a different GitHub account. GitButler knows which account belongs to which repository.

Pushing Branches and Creating Pull Requests

When you push a branch from GitButler, it sends it to the correct remote automatically. If you open the Pull Requests tab for a branch, you can create a new pull request without copying URLs or switching browsers or logging out of one account and into another. GitButler opens the pull request in the browser with the correct GitHub account signed in.

If you already have an existing pull request for the branch, GitButler shows it directly in the UI. If the branch lives on GitHub, you see it there. If it lives on your enterprise server, you see that instead. You can move between PRs from different accounts without touching any credentials.

This consistency feels especially powerful when you work on parallel projects that belong to different identities. GitButler becomes a one stop dashboard for every branch and pull request you have in motion.

Handling Self Hosted Enterprise Instances With Custom CSP

If your company uses a private GitHub Enterprise server that is hosted behind a firewall or that sits inside a custom domain, you might need to adjust GitButler’s Content Security Policy. GitButler ships with a strict CSP designed to block connections to unknown external hosts. This protects you from unwanted network requests but can also block a legitimate enterprise server.

If GitButler is blocked, you might see an error like:

Refused to connect to https://yourcompany.git/api/v3/ because it is not allowed by the Content Security Policy.

If you see something like this, the fix is simple. You can add the host to GitButler’s CSP configuration.

On macOS, the file lives here:

~/Library/Application Support/gitbutler/settings.json

On Windows or Linux, the path is similar inside your user application data directory.

Open the file and look for the extraCsp field. If it does not exist, create it. Then add the hosts you want GitButler to allow. The structure looks like this:

{
  "extraCsp": {
    "hosts": [
      "https://github.mycompany.com",
      "http://internal.gitserver.local"
    ]
  }
}

You can list as many hosts as you need. If your enterprise instance uses different base URLs for API calls, repository browsing, or authentication, add each one.

GitButler loads the CSP rules when it starts. After you update the settings file, quit GitButler completely and reopen it. Once it restarts, GitButler should be able to connect to your enterprise hosts without throwing CSP errors.

With custom CSP entries in place, GitButler behaves exactly the same with enterprise servers as it does with GitHub. You can clone, open branches, sync changes, and manage pull requests without interruptions.

Working across multiple GitHub accounts does not need to slow you down. GitButler makes it possible to juggle as many identities as you need without dropping into credential hell. You can connect personal accounts, work accounts, and any number of GitHub Enterprise servers. You can switch projects with no mental overhead and never worry about messing up your Git identity.

With custom CSP support, GitButler works even in network locked or heavily secured enterprise environments. If you build software across different organizations or contexts, this setup will save you a surprising amount of time.