Gitfence

Start new hires in their module, then widen access as trust grows

Day one doesn't need the whole codebase. Give a new developer their team's folders and types for the rest, and open more when it makes sense. Their clone just fast-forwards.

acme/shopon GitHubnew hire's clonesame clone, later
Everything, exactly as today.Week 1: their team's code, types for the core.Later: more access, and git pull just fast-forwards.
$ git clone [email protected]:acme/shop.git$ git clone https://gitfence.dev/acme/shop.git$ git pull # fast-forwards, no re-clone

Example: in week one a new hire edits apps/web/, reads packages/ui/, gets packages/core/ as types only and has no access to services/billing/ or infra/. Later, access widens and git pull fast-forwards.

The situation today

New hires usually get the whole repository on day one because the alternative is building a special sandbox. That means your most sensitive code reaches people still in probation, on laptops you've had for a week.

It also isn't great onboarding: a smaller, focused view with clear boundaries is easier to learn than a monorepo with everything in it.

A first-month view

PathAccessWhy
apps/web/Can editTheir team's code
packages/ui/Can readShared components
packages/core/Types onlyAPIs without the implementation
services/billing/No accessUntil they need it
infra/No accessPlatform team only

How Gitfence handles it

Start narrow

Give the new-hire group Can edit on their team's folders, Can read on shared code and Types only on the core.

Widen without disruption

When you grant more, their history moves forward with a commit called Gitfence: access updated. git pull fast-forwards; nobody re-clones.

Requests with an end date

They (or their agent) request a path with a reason and a duration. Approve it on the web or in Slack, for that person only.

Documents first

Require the employee handbook, security policy or IP assignment to be signed before any code is reachable.

Promotion is a group change

Move them to the core team group and they become a full-access teammate, which is free.

Previewing the repository as alice: she sees 15 of 17 files; 2 files don't exist for her, not even in historyPreviewing the repository as alice: she sees 15 of 17 files; 2 files don't exist for her, not even in history
Check before day one. Preview exactly what a new hire's clone contains.

What it won't do

  • A new hire who later loses access keeps whatever they already cloned. Gitfence controls what they get from now on.
  • Changing access adds a commit to their view's history rather than rewriting it.

Full security model and limits

Questions

Do new hires pay as restricted people forever?

Only while they're restricted. Move them to a full-access group and they stop counting.

Can a new hire still run the whole app locally?

If the hidden parts are needed at runtime, not fully yet. Types only covers compiling and type-checking, and Fenced CI runs the real tests (self-hosted today; on hosted, we set it up with you). Running hidden modules locally (compiled artifacts or service stand-ins) is on the roadmap.

Fence your first repository in minutes

Free for one repository and your own team. Add a restricted person and Pro is free for 14 days, no card.