Developers already have a collaboration system that works.

It is called git.

That sounds obvious, but a surprising number of developer tools still behave like git does not exist. They store important project data in private clouds, opaque workspaces, proprietary databases, or giant export files that nobody wants to diff. Then they bolt on “team sharing” later as a paid feature, usually with invites, roles, seats, syncing, workspaces, and some new mental model developers have to learn.

But developers already know how to collaborate.

We branch. We commit. We review. We merge. We revert. We blame. We tag releases. We keep history. We argue in pull requests. We use the same workflow for application code, infrastructure, documentation, migrations, tests, CI configuration, and deployment scripts.

So why not more of our tools?

Project Data Is Still Source Code

A lot of developer tooling produces data that is not technically “code,” but still behaves like source.

API collections are a good example. They describe real parts of a system: endpoints, headers, authentication, examples, request bodies, environments, scripts, and workflows. That information changes as the application changes. It has history. It has ownership. It benefits from review.

The same is true for database schemas, OpenAPI definitions, deployment configs, seed data, mocks, test cases, local development settings, and automation rules.

When those things live outside git, they become harder to trust.

You end up asking questions like:

• Who changed this?
• When did it change?
• Why did it change?
• Can I compare this to production?
• Can I roll it back?
• Can I review it before the team starts depending on it?

Git already answers those questions.

Export Files Are Not a Workflow

A common workaround is export/import.

Export the thing. Commit the exported file. Tell your teammate to import it. Hope they do not overwrite their local copy. Hope the next export does not reorder everything and create a useless diff. Hope nobody forgets which copy is the current one.

That is better than nothing, but it is not a real workflow. It is a side channel.

Export/import works fine for snapshots. It does not work well for living project data.

A real workflow should let the tool write structured files as you work. Changes should be reviewable. Small edits should produce small diffs. Teams should be able to branch, commit, pull, push, and merge without treating the developer tool as a separate universe.

That is the key distinction: git should not be an afterthought. It should be part of the tool’s storage model.

Developers Do Not Need Another Collaboration Model

A lot of modern tools try to own collaboration.

They create accounts. They create teams. They create workspaces. They create invite flows. They create permissions. They create billing tiers. They create a cloud sync layer. Then they ask developers to move their project knowledge into that system.

Sometimes that makes sense. Real-time collaboration is useful. Hosted services are useful. A shared cloud backend can be the right answer.

But it should not be the only answer.

For many teams, the repository is already the source of truth. Access control already exists there. Review already exists there. History already exists there. CI already exists there. If the data belongs to the project, putting it in the project repository is usually the least surprising thing to do.

That does not mean every tool needs to become a git client. It means more tools should respect git as a first-class place where developers keep important work.

Good Git Integration Is More Than “Save as JSON”

There is a lazy version of git support: dump one huge JSON file into a folder and call it a day.

That is not good enough.

If every change rewrites a giant blob, diffs become noisy. Merge conflicts become painful. Code review becomes nearly useless. Developers technically have the data in git, but they do not get the full benefit of git.

Good git-backed tooling should produce files that are meant to be read, reviewed, and merged.

That means:

• stable formatting
• predictable file names
• small files for small units of work
• local-only secrets kept out of commits
• shared configuration separated from private overrides
• sensible conflict behavior
• no pointless churn when nothing meaningful changed

The goal is not just to store data in a repository. The goal is to make the repository useful.

HarborClient Now Supports Git

This is one reason I like the direction HarborClient is taking.

HarborClient now supports git-backed collections, which means requests, environments, and collection metadata can live as files in a repository instead of being trapped inside an app database or passed around as exports. Git is treated as a first-class database provider alongside options like SQLite, MySQL, PostgreSQL, and Firestore. Collections are written to disk as structured JSON while you work. Each saved request gets its own file, which keeps diffs smaller and merge conflicts more localized. HarborClient also includes source control features in the app, including change indicators, commit, pull, push, and live reload after changes on disk. You can read the announcement here: HarborClient adds git support.

That is the right idea.

An API client should not force teams to choose between using the app and using their existing development workflow. If a team already reviews API changes in GitHub or GitLab, the API client should fit that process. If collections belong next to the app code, they should be able to live there. If someone wants to branch and experiment with a new endpoint design, that should feel natural.

Git support makes API collections feel less like app state and more like project assets.

Local-First Still Matters

Another benefit of git-backed tooling is that it reinforces local ownership.

There is a big difference between “your work is stored in our cloud account” and “your work is stored in your repository.”

Cloud services can be convenient, but developer tools should be careful about making the cloud mandatory. Not every team wants another account system. Not every project can put internal API details into a third-party workspace. Not every solo developer wants their workflow tied to a subscription.

Git is boring in the best possible way. It is portable. It is inspectable. It does not require a specific vendor. It works with GitHub, GitLab, Bitbucket, self-hosted servers, local repositories, and plain old folders.

That kind of boring infrastructure is exactly what developer tools should lean on more often.

Git Makes Tools More Honest

When a tool stores its data in git, it has to be more honest about what it is doing.

The files are visible. The changes are visible. The structure is visible. Developers can inspect the output, script against it, back it up, review it, and move it somewhere else.

That reduces lock-in.

It also raises the quality bar. A tool that writes unreadable garbage to disk is going to get judged for it. A tool that rewrites everything on every save is going to annoy people immediately. A tool that leaks secrets into committed files is going to lose trust.

That pressure is healthy.

Developer tools should not be magical boxes. They should be reliable layers on top of workflows developers already understand.

More Tools Should Work This Way

Git does not belong everywhere. Some data is too large, too noisy, too temporary, or too collaborative in real time for git to be the right storage layer.

But a lot more developer data belongs in git than currently does.

API collections belong in git. Environment templates belong in git. Mocks belong in git. Test scenarios belong in git. Tool configuration belongs in git. Anything that describes how a project works, how it is tested, how it is deployed, or how developers interact with it should at least have a clean path into source control.

The best developer tools do not ask you to abandon your workflow.

They meet you where the work already happens.

And for developers, a lot of that work still happens in git.