Do my branch protection rules still apply to Gitfence PRs?

Yes. Restricted people's work arrives as ordinary pull requests on GitHub, so required reviews, CODEOWNERS and status checks apply as usual. Gitfence also refuses pushes to the default branch.

Gitfence vs CODEOWNERS and branch protection

Short answer: CODEOWNERS, branch protection and rulesets control changes: who must review, which branches accept pushes, and (with push rulesets) which paths may be modified. None of them limit who can read a path. Anyone with read access to the repository can clone all of it. Gitfence limits reading, and works alongside these rules rather than replacing them.

What CODEOWNERS and branch protection do well

A CODEOWNERS file requests reviews from owners of matching paths, and branch protection can require their approval. Push rulesets can block pushes that change specific file paths, and are available for private repositories on GitHub Team. These are native, free with your plan, and excellent at governing what gets merged.

Where it falls short for partial access

No read restriction: a contractor with read access can clone the pricing engine even if they can never change it.
Reviews happen after the code was written, by someone who could see everything.
They can't give someone types instead of source.

Side by side

	CODEOWNERS & branch protection	Gitfence
Restricts reading a path	No	Yes
Restricts changing a path	Yes (push rulesets, required reviews)	Yes (push validation)
Review routing	Yes	Uses yours: PRs land on GitHub
Per agent	Via tokens with repo-wide scope	Agent tokens with the person's view

Which to choose

Choose CODEOWNERS & branch protection when

Everyone with access may read everything, and you only need to govern changes.
You need review routing in a repository everyone already sees.

Choose Gitfence when

Some people or agents must not read some paths at all.
You want both: keep CODEOWNERS and branch protection for your team, add Gitfence for restricted people.

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.