Can I split the repo later if Gitfence doesn't work out?

Yes. Gitfence doesn't change your GitHub repository's layout or history, so nothing locks you in.

Do my full-access teammates use Gitfence?

No. They keep using GitHub directly. Only restricted people and their agents clone through Gitfence.

Gitfence vs splitting a repo into separate repos

Short answer: separate repositories give you real, native GitHub permissions, and if your code already has clean boundaries they may be all you need. If the protected code is woven into the rest (shared types, one build, one CI), splitting costs you atomic changes, shared history and a working local build. Gitfence keeps one repository and gives each person a view of it.

What splitting into separate repositories does well

Move the sensitive code (say core/) into its own private repository and publish it as a package, or vendor it in as a build artifact. Contractors get access to the app repository only. It uses GitHub's own access model, needs no extra service, and every tool understands it.

Where it falls short for partial access

A change that touches both sides becomes two pull requests, two reviews and a version bump, merged in the right order.
History is split at the moment you split, and moving files between repos later loses blame.
People without access to the private repo need a published build of it to compile and test, which means a package pipeline and credentials to manage.
Every new boundary (a second contractor, an agent with a different scope) means another split.

Side by side

	Splitting into many repos	Gitfence
Read restriction	Per repository	Per folder or file, per person
Atomic cross-cutting changes	No, one PR per repo	Yes, one repository
Restricted people can compile	If you publish builds or packages	Types only serves the API of Go, Python and TypeScript code
Tests against hidden code	Only through published builds	Fenced CI on the real code, no network
Changing who sees what	Move code between repos	Change a setting; their history fast-forwards
Extra service in the path	None	Gitfence, for restricted people only

Which to choose

Choose Splitting into many repos when

The protected code is already a separate service or library with a stable API.
You want zero third parties in your git path.
Boundaries rarely change.

Choose Gitfence when

The code is one product with shared types and one build.
Different people need different slices, and the slices change.
You want contractors' work to arrive as ordinary PRs on the real repo.

Gitfence's own trade-offs

It adds a service between restricted people and GitHub, hosted by us or self-hosted (your core team doesn't use it).
It supports GitHub only today (github.com, and GitHub Enterprise Server when self-hosted), and Types only covers Go, Python and TypeScript.
Hidden modules can't yet run on the restricted person's machine; Fenced CI runs the tests instead.
It's a young product without a SOC 2 report yet (it is on our roadmap). See the security page for what's tested.