Multiple Git repositories. One workspace.

No. This is a fundamental requirement of the design. Your public repository stays a completely standard Git repository - fork, clone, branch, commit, push, pull request, all without GitOne installed and without any knowledge that it exists.

Nothing breaks. Each managed repository under .gitone/repositories/ is an ordinary Git directory with its own metadata, index, HEAD, refs and hooks. Point plain git at one with --git-dir and it behaves exactly as it always did. There is no proprietary format and no lock-in.

No, and that is a decision rather than an unfinished feature. Splitting one history along path ownership rewrites every commit, and each commit that touched two repositories becomes two unrelated commits describing something that never happened. It also cannot deliver what it appears to promise: if the repository was ever pushed, the old objects stay on the forge no matter what you rewrite locally. So migration converts the project layout, not the history. The managed repositories start empty, and your complete old repository - every commit, branch, tag, stash, reflog, hook and remote - is copied to a verified backup under .gitone/migration-backup/ that GitOne never removes, readable with gitone backup git -- log --all and restorable with gitone backup restore. If you do want a split history, rewrite it with a dedicated tool before you migrate.

No. It never reads your file contents. There is no secret scanning, no data classification and no entropy check. A private key inside src/ is published like any other owned file unless its path is explicitly covered by rules.protected_paths. GitOne enforces where a path may be published - not what is inside it.

No, and it is important to be clear about this. Everything sits in one directory that your shell, editor, backup tool and every other local program can read. GitOne is not an access-control boundary. It decides which repository may publish a path, which is a boundary that matters when something leaves your machine.

The file itself, no - it is a reserved path. gitone add .gitone.local.yml refuses with PATH003, listing it in a repository is CONFIG003, and if it reaches an index another way gitone doctor reports it. Setup writes it into .gitignore for the same reason. What you can do is declare those repositories in the committed .gitone.yml instead, and sometimes that is the right call - a team where everyone should get the same repositories, for example. Just be clear about the price: their names, remote URLs and path patterns become readable for everyone who clones, which sketches your internal structure even though not one private file is published. That is a judgement only you can make, and the default is the careful one.

Not yet. Linux and macOS, amd64 and arm64. Windows is deferred rather than rejected, but nothing is promised.

There is no .git/ in the project root, so bare git commands find nothing. You can point Git at a managed repository with --git-dir and it will work - but every safety check GitOne performs is bypassed when you do, which is exactly the situation the tool exists to prevent. Use it to inspect, not to publish.

Yes, with plain Git against one managed repository at a time: git --git-dir=.gitone/repositories/{name} {command}. GitOne rejects unsupported commands instead of forwarding them. Running plain Git bypasses GitOne’s safety checks and multi-repository coordination. Commands that modify branches, refs, indexes or working-tree files can leave the managed repositories out of sync. Use this only when you understand the resulting state, then check the project with gitone status and gitone doctor.

Yes. Every operation is a native git invocation against a real repository, so your Git configuration, hooks, credential helpers, commit signing and Git LFS filters all run as they normally do. GitOne stores no credentials of its own.

Not yet. They are rejected with CLI001 rather than forwarded to Git, because coordinating them across several repositories safely is design work that has not happened yet. Resolving a diverged branch with plain Git and then returning to GitOne is the supported path today.

No. Submodules are not supported at all, and a nested or bare Git repository inside a managed path is reported as PATH003 rather than silently handled.

Only as a deliberate alias inside one repository, such as .claude/skills -> ../.agents/skills. The stored target has to be relative and non-empty, resolve inside the project, exist as a regular file or a real directory, be reached without passing through another link, and belong to the same repository as the link. A directory target needs at least one relevant path below it, all owned by the same repository. GitOne owns the link path itself and never traverses it. Absolute, escaping, dangling, cross-repository, chained and cyclic links are PATH003, and so is any link that is or reaches .gitone.yml, .gitone.local.yml, .gitignore, .gitone/, .git/ or a protected path - GitOne never opens such a target.

The operation stops with PATH002. Duplicate patterns are rejected earlier as invalid configuration with CONFIG003, but patterns from two repositories are allowed to overlap in theory - the error lands on the concrete file, not on a guess about one. There is no priority rule and no most-specific-match rule - deliberately, because either one turns "where does this file go?" into something you have to work out instead of read.

The tool has none. GitOne runs entirely on your machine with no telemetry, no update check and no account, and contacts nothing but the Git remotes you configured yourself.

Yes, and not only those two. Remotes are configured per repository, so GitHub, GitLab, Codeberg, Gitea, Forgejo, Bitbucket, a company server or a bare SSH path can sit side by side in one working directory - GitOne calls the same native git for each. Only origin is used by fetch, pull and push. A repository without a remote works for every local command; only pushing it fails.

No. Those orchestrate builds, tasks and dependencies inside one repository. GitOne does not know what a build is. It decides which of several repositories owns which path, and it is happy to sit underneath any build tool you like.

They use gitone instead of git, read gitone status --json for machine-readable state, and get a hard refusal instead of a guess when a file is unassigned. There is a ready-made instruction block above that you can paste into your AGENTS.md or CLAUDE.md.

MIT. GitOne is open source and the underlying repositories stay compatible with standard Git, so public contributions work exactly as contributors expect.