nit

The gap nit fills

GitHub, GitLab and Gitea all grant access per repository. None of them can hide a file inside a repository from someone who can clone it.

So teams split repositories until the boundaries match the permissions — and then live with the submodules, the version skew and the cross-repository changes that nobody can review in one place. Or they keep one repository and accept that every developer, every contractor and every CI job can read the production credentials in it.

nit is the third option. One repository, and the permissions inside it.

Absent, not hidden

A file a developer may not read is not encrypted or greyed out on their machine. It is not there. There is nothing on that disk to leak.

Fail-closed writes

A push touching a path its author may not write is refused whole, with the rule that refused it and what to do about it. Not silently stripped.

Ordinary git

Developers commit, branch and merge as usual. nit sits between them and the forge; the forge itself is unchanged.

Answerable

Every decision records who, what, when, and under which rule — against a policy version you can replay.

In one minute

nit clone backend-api
cd backend-api
ls
# src/  docs/          ← secrets/ is not here. Not hidden: absent.

vim src/server/api.go
git commit -am 'fix the handler'
nit push -m 'fix the handler'
# Pushed 1 file(s) to backend-api@main as 978464d55d39

And when the rules say no:

nit push -m 'update the token'
# nit: the patch touches paths you may not change
#
#   secrets/prod.env (create)
#       refused by rule secrets-are-platform-only
#       Production secrets are owned by the platform team.

Nothing reached the forge.

Where to go next

What nit doesThe problem, the shape of the solution, and what nit does not do.

InstallA complete environment with a Gitea forge, in one command.

Filtered projectionsThe one idea that explains everything else about nit.

Writing a policy bundleRules, groups, subtrees and exemptions — reviewed like code.