For engineering teams of 3–50 and the people who lead them
Your team's Git practice is currently a set of habits, held in different heads.
macOS 12+ · The recovery layer needs no account and no network · The shared layer needs both, and this page says where the line is
Four problems that look like Git problems and aren’t
Practice is inconsistent and invisible
One engineer rebases, one merges, one force-pushes on Fridays. Nobody knows which until something breaks. The convention exists in a wiki page written eighteen months ago by someone who has since left.
Juniors are afraid of rebase: correctly
The fear is rational: the operation is destructive, the client gives no preview, and the recovery procedure is “ask the senior who is in a meeting”. So they avoid it, branches drift, and the merges get worse.
Nobody can see who did what
When main gains a commit nobody recognises, reconstructing the sequence takes an afternoon of git log, chat scrollback and guesswork.
Onboarding costs more than anyone admits
A new hire spends their first fortnight learning the repository layout, the branching convention, which repositories they actually need, and which operations are effectively forbidden, largely by asking people who have other work.
None of these are fixed by a better graph view. They’re fixed by putting the rule, the record and the safety net inside the operation.
The safety net is per machine, and it lands first
Before any of the shared machinery, every engineer who installs GitAegis gets the same thing the solo edition gives: a plan before a destructive operation, a six-domain capsule written before the first command, a refusal when that capsule cannot be written, an Operation Journal of everything that ran, and a timeline of what happened to the repository.
That part needs no account, no organisation and no network. A team of five is five machines that each stopped losing work, before anybody has agreed on a convention.
Shared workspaces: the repository list stops being folklore
A workspace is a named scope in your organisation holding the repositories a group works on, with the provider binding for each, plus its Change Sets and the policies that apply to it. A new engineer joins the workspace and sees the right repositories, instead of assembling a list from a wiki and three conversations.
Membership and roles are organisation-level: owner, admin and member. A person can belong to several workspaces and a repository can appear in more than one, but a role is held across the organisation rather than refined workspace by workspace.
What stays local: capsules, the Operation Journal and the Flight Recorder are per device and are not shared into a workspace. A workspace coordinates work. It does not publish your machine’s history to your colleagues.
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: one change, several repositories, one record
A Change Set is a product change that spans more than one repository: the branches, the commits and the order they have to be published in. The dependency graph rejects cycles and names the cycle it found, and the publish order is topological and deterministic rather than whatever you remembered.
Every mutation it performs goes through the same orchestrator as everything else, so each one is planned, journaled and checkpointed. And it never claims the set published indivisibly: a partial failure produces a compensation plan listing exactly what succeeded, what failed, and what was not attempted.
Approvals are recorded against the Change Set as a decision by a person, with a note and a timestamp.
- One product change, several repositoriesthe branches, the commits, and the order they have to be published in
- Dependency graphrejects cycles, and names the cycle it found
- Topological publish orderdeterministic, rather than whatever you remembered
- Every mutation planned, journaled, checkpointedthrough the same orchestrator as everything else
- Partial failure → compensation planexactly what succeeded, what failed, and what was not attempted
Approvals are decisions by people
Recorded against the Change Set with a note and a timestamp, not a merge precondition, and not your provider’s review.
Branch leases: two people, one branch, one holder
A lease stops two sessions (two people, or a person and an agent session) from rewriting the same branch at once. It is held for a fixed term, renewed by the holder while the work is live, and released by the holder when it is done; a lease nobody renews expires rather than blocking the team indefinitely.
The lease shows up where it is useful: as a precondition in the operation plan, before the operation runs, in the same place a dirty working tree appears.
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.
Policy: your rules become preconditions
The policy engine evaluates a documented rule catalogue when the plan is built and again immediately before execution. The rules it enforces are specific: protected branches, force push with no lease basis, a simulated preview required before a destructive operation, --no-verify hook bypass, commit signing, permitted author domains, and branch and commit-message conventions.
Precedence runs organisation → team → workspace → repository, and a rule locked at a higher scope is not weakened by a lower one, so the resolved rule set is predictable rather than emergent. Where a rule permits an override (and some have to, or nobody can work) the override is recorded with the actor and the reason.
What the signature is worth, precisely: the client verifies the organisation document before applying it and rejects one that is unsigned, fails verification, or comes from an organisation the device is not bound to. That signature is a Ed25519 signature whose private key never leaves the service, so treat it as evidence against accidental change rather than a control that survives a determined one.
- Organisation
- Team
- Workspace
- Repository
A rule locked at a higher scope is not weakened by a lower one.
The resolved rule set becomes preconditions
Evaluated when the plan is built, and again immediately before the operation runs.
- Overrides are recorded
Where a rule permits one, the override carries the actor and the reason.
- The document is verified before it applies
Unsigned, failing verification, or from an organisation the device is not bound to: rejected. The signature is Ed25519, so a member holding the verification key cannot produce a document that passes.
What a nervous junior's rebase looks like on a team that runs GitAegis
The plan opens before anything runs.
Intent, risk level, the preconditions checked, the exactgitcommands, the checkpoint that will be taken, and the rollback path. Reading a plan is teachable in a way that “are you sure?” is not.Preconditions include the team's rules.
A protected ref, a force push with no lease basis, or a branch lease held by somebody else fails the precondition and vetoes the operation, in the same place, and in the same words, as a dirty working tree.The capsule is taken, or the operation doesn't run.
Refs, index, staged changes, working changes, untracked files, operation state. No capsule, no operation, and no control in the interface that waives it.It's journaled on the machine that ran it.
The Operation Journal holds the plan, the exact commands, the checkpoint and the outcome, searchable, so the reconstruction that used to take an afternoon takes a query.If it was wrong, they restore it themselves.
Per domain, from the capsule, without needing a senior engineer to translate the reflog for them. The training effect is the point: after a fortnight of reading plans before destructive operations, the operation stops being frightening because it stops being opaque.
What a team gets
Shared workspaces
Repositories, their provider bindings, Change Sets and the policies that apply, in one named scope.
Read moreChange Sets across repositories
A dependency graph that rejects cycles, a deterministic publish order, and a compensation plan when part of it fails.
Branch leases
A fixed term, renewed by the holder, released by the holder, and surfaced as a precondition in the plan.
A policy engine with a named catalogue
Protected branches, force-push rules, destructive-operation simulation, hook bypass, signing, author domains, and naming conventions.
Read moreRecorded overrides
Every exception carries the actor and the reason it was taken, because a policy with an unrecorded override path tells you nothing.
An operation record per engineer
The Operation Journal on each machine: intent, risk level, exact commands, checkpoint and outcome, searchable.
Read moreSemantic Composer
Proposes commit groupings from your real diff (deterministic and offline, not a model) and applies them through the same orchestrator, preview and capsule.
Cloud capsule backup
Opt-in per repository, and encrypted on the device before anything leaves it, so a repository nobody opts in is never transmitted.
Read moreGitHub
Connect an account, read pull requests, checks and reviews where the work is, and open a pull request from a Change Set.
Read moreWhat a team keeps when things change
A removed member’s local work is theirs
Capsules, the journal and the timeline are files on their machine. Removing someone from the organisation revokes workspace and policy access; it does not reach into a laptop and delete anything.
Changing plan doesn’t destroy history
Local capsules stay on disk. What a plan governs is the retention window that applies to newly created capsules, not the ones already written.
The local edition never depends on the cloud
If your network is down, or an organisation service is unreachable, every local operation, every capsule and every restore keeps working. Workspace state and policy refresh are what pause.
Onboarding a new engineer
Day one, in order: install GitAegis, confirm Git 2.38.0 or newer is present, join the workspace, and the repositories arrive with their provider bindings instead of as a list somebody dictates. The policy that applies is readable in the client rather than tribal.
Then the part that saves the fortnight: the new engineer runs destructive operations with a plan in front of them and a capsule behind them. They do not need to have internalised your conventions before they are allowed to touch a branch, because the conventions are evaluated as preconditions and the mistakes are reversible.
What this does not do
Stated before you plan a rollout around it
- The shared layer needs an organisation service; the recovery layer does not. The desktop build you can install today has one account-backed feature, the AI commit report, and it is not part of the shared layer. Workspaces, policy distribution, the organisation audit trail and capsule backup are the part that depends on an account and does not run yet.
- Client policy is not server-side enforcement. It governs what GitAegis will do. Somebody running
git push --forcefrom a terminal is outside its reach, which is what your provider’s protected-branch settings are for, and GitAegis’s policy is designed to sit alongside them rather than replace them. - It is not a code review tool, and it is not a CI system. An approval recorded on a Change Set is a decision by a person with a note and a timestamp. It is not bound to a specific commit, it is not the approval on your provider’s pull request, and neither it nor a CI result acts as a merge precondition.
- A branch lease is a coordination control, not a server-side lock. It vetoes operations inside GitAegis, and only the holder can release one.
- Capsules, journal and timeline are local and per device. They are not pooled into a team feed. Capsule backup is per user and per repository, and opt-in.
- Recovery still has its stated boundary. A capsule, a Flight Recorder state hash, or a ref that still points at a commit. Outside those it cannot, and rebase state and config are not restored from a capsule.
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