Virtual Repositories · Share mode ⌘6
Give someone the part of a repository they need, as a real Git repository.
GitHub.com sources in the current release · Named recipients · Read-only or pull-request access · Production qualification in progress
01Source
GitHub.com repository
02Scope
selected paths + exclusions
03Virtual Repository
new commits and Git objects
04Recipient
standard Git clone
Not ready for work you depend on
The account, the owner controls and the recipient surfaces are built. Provisioning a share end to end, public Git access, synchronisation, recovery and revocation are still being finished, so a share may stay in Preparing. Use it to judge the shape of the feature, not to give somebody access they need today.
Repository access is usually much wider than the work
Monorepos make ownership and reuse easier inside a company, but they make outside access awkward. A new repository loses the connection to the source. A full repository grant exposes unrelated code. Copying files by hand stops being useful as soon as either side changes them.
A Virtual Repository keeps a deliberate source binding and writes a new Git history made from the allowed paths. It is independently owned, granted, paused, revoked and deleted. Several Virtual Repositories can come from the same source without sharing recipient access.
A contractor who needs one folder should not need a clone containing every other product, customer and year of history.
Owner journey
From source repository to recipient clone
The desktop creates and changes the scope. The website provides emergency access controls and the recipient handoff.
Choose the source and review its exact commit.
Share mode fetches the selected GitHub.com branch, pins the commit under review, and confirms through the connected GitHub account that you may read that repository.Select files, folders and exclusions.
The review shows the effective paths and calls out unsupported entries before anything is published. Suspected credentials are reported as warnings and do not block sharing. Unsupported Git LFS pointers must be excluded.Choose people and what each person may do.
A recipient can receive read access, or write access when the share uses the pull-request bridge. External recipients accept an invitation with the verified email address it names.Review the consequences and create.
Creation is asynchronous. The source is projected into an isolated bare repository, access policy is installed, and the share becomes cloneable only after the serving generation is acknowledged.The recipient uses standard Git.
The website supplies the clone URL and a short-lived Git credential. Clone, fetch, pull, checkout, branch, commit and permitted push operations run through a normal Git client; GitAegis does not need to stay open.
Recipient Git flow
Accept
verified account invitation
Credential
short-lived and revocable
Clone
advertised projected refs only
Work
branch, edit and commit locally
Push
refused in read-only; reviewed in PR bridge
Scope rules
The rule is about the path after the change
The same effective-scope calculation drives review, projection and later synchronization.
A selected file is exact
Selecting one file shares that path. Siblings are not included, and renaming the source file does not silently retarget the rule.
A selected folder follows its descendants
Files and folders created beneath an included folder join the next successful projection. Explicit exclusions still win.
Moves follow the resulting path
A file moved outside the allowed scope leaves the next projection. A file moved into scope joins it. Moves within scope remain visible.
Each recipient has a separate grant
Access belongs to a verified account, with its own read or write role and optional expiry. Removing one recipient does not change another recipient's grant.
Permissions
Read-only and pull-request access have different endpoints
Neither mode gives a recipient direct write access to the source repository's default branch.
Clone, fetch and pull
The recipient can read the projected repository and create any local commits or branches they want. Every push to GitAegis is refused by the server.
Push a branch, open a pull request
The recipient pushes their own branch to the Virtual Repository. After validation and recovery evidence, GitAegis translates the allowed change to a provider branch and opens a pull request. It never merges that pull request automatically.
Git boundary
The worktree is not the security boundary
A safe Virtual Repository must exclude restricted Git objects as well as restricted files.
GitAegis creates new commits, trees and blobs for the selected view. It does not serve the source repository with a filtered checkout on top. Source commit ids and Virtual Repository commit ids are different because their trees are different.
Hidden branches, tags and source object ids are not alternate paths into the source history. A recipient is authorized for the current serving generation and its advertised refs; narrowing the scope rotates that generation and requires a new clone.
Current boundaries
Only GitHub.com repositories are accepted as sources in this release.
Git LFS payloads are not projected. A detected LFS pointer blocks publication.
Submodule pointers inherited through a selected folder are omitted; selecting one directly is refused.
Git does not store empty directories, so selecting a folder does not make an empty directory appear.
Provisioning and source synchronization are asynchronous and must show their state; they are not instant.
Revocation stops new service access. It cannot recall files a recipient already cloned or copied.
Your shares
Manage access from the app, inspect it here
Create and change Virtual Repositories from Share mode in the desktop app. Use the website to inspect access, receive an invitation, mint a Git credential, or stop access.