If your team already treats API definitions as source code—reviewed in pull requests, branched for experiments, deployed from main—your HTTP client should fit that workflow too. HarborClient now supports git-backed collections: store requests, environments, and collection metadata as files in a repository, edit them in the app, and commit, pull, and push without leaving HarborClient.

This isn’t export/import as a side channel. Git is a first-class database provider, alongside SQLite, MySQL, PostgreSQL, and Firestore. Link a local clone, and HarborClient writes your collections to disk as structured JSON while you work.

Why git-backed collections?

HarborClient has long supported sharing collections through export files, database invites, and team hubs. Each approach fits a different need:

• Export/import — great for one-off snapshots
• Shared databases — live collections on a remote backend
• Team hubs — token-based sharing through HarborClient Team Hub

Git is for teams that already collaborate through repositories: readable diffs, branches, code review, and history you can blame. Put collections next to your app code or infrastructure configs and use the same rituals you use for everything else.

How it works

When you add a Git database connection, HarborClient stores data under a configurable subdirectory in your repo (default: .harborclient/). Each collection becomes a folder. Each saved request becomes its own file—so a change to one endpoint doesn’t rewrite a giant monolithic JSON blob.

.harborclient/

.gitignore

collections/

<uuid>-<slug>/

collection.json # name, variables, headers, auth, scripts, folders

requests/

<uuid>-<slug>.json # one request per file

environments/

<uuid>-<slug>.json

That layout keeps diffs small and merge conflicts localized. If two people edit different requests, git can usually merge cleanly. If they edit the same request, you get a conflict in one file—not across an entire collection.

Variables marked Share are written to disk with their values (for team-visible config). Variables you keep private are masked on disk, same as when you export a collection manually—so secrets don’t accidentally land in the repo.

For environments, HarborClient generates a .gitignore that ignores local override files (environments/local*.json and environments/*-local.json). Commit shared environment definitions; keep machine-specific secrets in ignored local files.

Source control inside the app

You don’t have to drop to a terminal for every sync.

• Uncommitted changes badge — Git-backed collections show an amber badge in the sidebar when the working tree has changes under the HarborClient subdirectory.
• Source control panel — From a collection’s row menu, open Source control to see your branch, change count, recent commits, and actions to Commit, Pull, and Push.
• Live reload — After a pull—or when files change on disk from an external git pull—HarborClient reloads collections and refreshes the sidebar. A file watcher and focus-based refresh help keep the UI aligned with the repo.

If merge conflict markers appear in JSON files, HarborClient surfaces the conflict count in the source control panel and warns you with a toast. Resolve the markers in your editor, then pull or reload again.

Getting started

1. Clone your repository locally (use an HTTPS URL).
2. Open File → Settings → Databases and click Add database.
3. Choose type Git and fill in:
   • Repository path — path to your local clone
   • Repository URL (HTTPS) — remote used for fetch and push
   • Branch — e.g. main
   • HarborClient subdirectory — default .harborclient
4. Authenticate if the repo is private (see below).
5. Restart HarborClient so the connection mounts at launch.

On first use, HarborClient creates the directory layout and default .gitignore.

Authentication for private repos

HarborClient talks to remotes over HTTPS using isomorphic-git. Tokens are stored encrypted on your machine—the same secret storage used for AI API keys—not in plaintext connection settings.

You have two options:

Method	Best for
Personal access token (PAT)	GitHub, GitLab, Bitbucket, self-hosted git—any HTTPS host
Authorize with GitHub	GitHub.com via OAuth device flow: approve in the browser, complete in Settings

Note: SSH remotes and SSH keys are not supported in-app. If your team uses git@github.com:... URLs day to day, create a PAT for HTTPS access, or use your normal git tooling for push/pull while still editing collections in HarborClient.

Sharing without invite tokens

Git-backed collections don’t use HarborClient Invite tokens. Sharing is through the repository itself: grant access to the repo, and teammates add the same Git connection pointing at their own clone. Everyone works from the same files, with git as the coordination layer.

Collections on a git connection still show a provider badge in the sidebar (like other non-active databases), so you can tell which repo backs which collection.

A practical workflow

A typical team flow might look like this:

1. Add a Git database connection to your API definitions repo.
2. Create or import collections; HarborClient writes files as you edit.
3. Commit from the Source control panel with a clear message.
4. Push; teammates pull (in HarborClient or their terminal).
5. Review API changes in GitHub/GitLab like any other code change.

Branches work too: point your connection at a branch, experiment in HarborClient, merge through your normal git process.

Try it

Git-backed collections are available in HarborClient today. If you’ve been exporting .json files into repos by hand, or maintaining duplicate copies of the same API set, this is the workflow you were approximating—now built into the app.

File → Settings → Databases → Add database → Git

Clone, connect, commit. Your API collections belong in git alongside everything else you ship.