GitAegis Team · Review mode ⌘4 · Requires an account
Coordination that shows up as a precondition, not as a message in a channel.
Team plan · Requires an account · Local recovery works with no account and never depends on this
A Change Set names the work
A title and description, the branch and its base, the commits, and the members working on it: tracked in the workspace.
Approvals are recorded
A decision with an optional note, attributed to a member and stamped with the time.
The merge stays with your host
An approval is not a merge gate and does not tell the client to refuse anything.
Most team Git problems are coordination problems wearing a Git costume
Two people rebase the same branch an hour apart. Someone force-pushes over a colleague’s work because their local view was twenty minutes stale. An agent session and a human are both on feature/payment-retry and neither knows.
None of those are Git failures. Git did exactly what it was asked. They are failures of knowing what someone else is doing, and the usual fix is a message in a channel and a convention nobody is obliged to follow.
A held lease fails the same way a dirty working tree fails: named, in the plan, before the capsule is taken and before any command runs.
GitAegis puts the coordination signal where the decision is being made: in the operation plan, as a precondition that can veto.
A session holds a lease on feature/payment-retry
Human or agent: visible to the workspace, renewed to survive, expiring within 24 hours if it stops.
Another session plans a rewrite of that branch
Rebase, force push, reset or branch deletion: the plan's preconditions run first.
The precondition fails, and says why
It names who holds the lease and when it expires. No command has run and no capsule was needed.
Shared workspaces
A workspace is a named scope inside your organisation carrying the state a group of people needs to share.
Repositories. The set the workspace works on, so a new member joins and sees the right repositories rather than assembling their own list from memory.
Members. Who is in the organisation and what they can do, by the roles below.
Change Sets. The unit of work under review, described next.
A member can belong to several workspaces, and a repository can appear in more than one. What does not come with them is your local state: capsules, the Operation Journal and the Flight Recorder timeline are per device, and are not shared into a workspace.
A workspace
- Repositoriesthe set the workspace works on
- Membersorganisation members, by role
- Change Setsthe unit of work under review
- Sessions and leaseswho is active, and on which branch
Stays on your device
Capsules, the Operation Journal and the Flight Recorder timeline are per device, not shared into a workspace, and not uploaded because you joined a team.
Change Sets
A Change Set is a coherent unit of work (a branch, its commits, its intent and its reviewers) tracked in the workspace rather than only in a provider’s web UI.
What it holds. A title and description, the branch and its base, the commits, and the members working on it.
Approvals. A member records a decision on the Change Set, with an optional note, attributed to them and stamped with the time. It is a record of what a colleague said about a piece of work, held where the team can see it.
What an approval is not, yet. It is not recorded against a specific commit, it is not dismissed when new commits land, and it is not a precondition the merge plan checks. A Change Set with two approvals tells you two people approved; it does not tell the client to refuse a merge, and this page will not imply that it does. The control that holds regardless of client is branch protection on your host.
Agent sessions and branch leases
A lease lives 24 hours. Then the branch frees itself.
Automated sessions are a normal part of a repository’s life now. An agent on a branch is a participant, and it needs the same coordination a person does. Arguably more, because it works faster and does not read the channel.
Sessions are visible.
A session (human or agent) declares itself to the workspace with an identity, the repository, the branch and its purpose. The workspace lists what is active and what each one is on.
Branch leases.
A session takes a lease on a branch. While it is held, another session attempting a rewriting operation on that branch (rebase, force push, reset, branch deletion) fails the precondition and sees who holds the lease and when it expires.
A lease lives 24 hours.
It has to be renewed to survive, so a session that dies, hangs or loses the network stops renewing and the branch frees itself. That matters more than it sounds: a coordination system that requires a human to clean up after a crashed process ends up as a permanently blocked branch.
The holder releases it.
Release is the holding session's to make. There is no handover request and no administrative force-release: a lease you want back before its time is a conversation, and the 24-hour ceiling is what stops that conversation being urgent.
takenA session takes the lease on
feature/payment-retryHuman or agent: listed by the workspace, with its identity, the repository and its purpose.
heldWhile it is held, a rewrite by anyone else fails its precondition
rebaseforce pushresetbranch delete- destructive
The failed plan names who holds the lease and when it expires. No command has run.
renewedIt has to be renewed to survive
Renewal is the holding session’s heartbeat, and the only thing keeping the lease alive.
releasedThe holder lets it go
Release is the holding session’s to make: nobody else’s.
expiredThe session dies, hangs, or loses the network
It stops renewing, and within 24 hours the branch frees itself. No human cleanup after a crashed process.
Leases advise. They do not lock the repository.
A lease is a precondition in GitAegis’s operation model. Someone in a terminal can rewrite the branch anyway. GitAegis has no veto over your shell, and a page that implied otherwise would be selling you a control you do not have.
What it does do is make the conflict visible before it happens for anyone working in the client, and put the resulting ref movement on the Flight Recorder timeline afterwards, whoever caused it.
Roles
Three roles, defined at the organisation. They are deliberately few, and each one means something specific.
Owner
Full administrative control of the organisation: members and invitations, workspaces, and publishing the organisation's policy document.
Cannot read a member's local capsules, journal or timeline. Those are on the member's device and are never uploaded to the organisation.
Admin
Manages workspaces, their repositories and their membership.
Cannot remove the organisation's owner or change who owns it.
Member
Works in the organisation's workspaces: repositories, Change Sets, approvals and branch leases.
Cannot manage the organisation's membership.
Roles are organisation-wide. A member is not an admin of one workspace and something narrower in another. The refinement per workspace does not exist, and neither does a read-only viewer role. If your organisation needs a colleague who can see a repository and change nothing, that boundary is not available here yet.
Where the local recovery layer sits in all this
It does not move. Capsules are captured on the device that ran the operation, stored locally, and restored locally. The Operation Journal and the Flight Recorder are per device. None of that is shared into a workspace, and none of it is uploaded because you joined a team.
What a workspace adds is coordination: shared Change Sets, recorded approvals and branch leases. What cloud capsule backup adds (separately, and opt-in per repository) is the ability for your own capsules to survive your own machine.
What workspaces do not do
Where the boundary is
They do not replace your Git host. GitHub, GitLab and everywhere else remain where your repositories live, where branch protection is enforced server-side, and where merges happen. Workspaces coordinate the people and sessions working on them.
Leases are advisory. A lease is a precondition in the client. It cannot stop a git push --force from a terminal, a CI job, or another client. If you need a hard block, configure branch protection on your host, and GitAegis will show you that rejection too.
Approvals are a record, not a gate. They are not enforced by your provider, and they are not currently checked as a precondition by the client either. Enforcement that holds regardless of client belongs in your host’s branch protection rules.
Capsules are not shared. A colleague cannot restore from your capsule and you cannot restore from theirs. Capsules are per device and, when backed up, encrypted with a key GitAegis does not hold.
Things that are not built
No provider linkage on a Change Set. A Change Set does not bind to a pull request or a merge request, so review state and CI results do not flow between them. Review comments, threads and diffs still live with your provider. What the integration does cover →
No notification service. There is no product notification for a requested review, a lease conflict or a CI result: no in-app feed, no email routing, no read state, no quiet hours. A workspace is something you look at, not something that reaches you.
Invitations are not delivered by email. An invitation produces a token that an owner passes to the person joining. Nothing sends it for you, and until that changes, treat the token as a credential and send it accordingly.
Workspaces need an account and a Team plan. Everything in the recovery layer does not. If a subscription lapses, the local edition keeps working and the workspace features stop.
Questions about teams
GitAegis Cloud
Your recovery history shouldn't live on one laptop.
Capsule backup, multi-device recovery, shared workspaces, and org policy.
30 days of Pro. No card is taken, so nothing is charged and nothing renews by itself. When it ends, GitAegis keeps opening your repositories: history, undo, capsule restore and export never stop. What waits for a subscription is making new work.
What Cloud adds
Capsule backup
encrypted on your device, uploaded after the operation finishes
Multi-device recovery
restored on a replacement machine with your recovery key
Shared workspaces
Change Sets, sessions, and branch leases
Org policy
signed rules, applied as preconditions