Work with Git repositories.

Choose the project and the access you need.

Any project member can browse an Active or Archived repository. A signed-in non-member can read only a repository whose organization, project, and repository have all been explicitly published.

Create an empty repository.

1. Open Code.Select the organization and project that will own the repository, then choose Repository.
2. Name the repository.Enter a display name and review the generated slug. The slug becomes part of the browser and HTTPS Git URL.
3. Add a description.The rich-text description is optional and can be revised later from repository Settings › General.
4. Create it.Mozaic reserves the identity, provisions Git storage, and then moves the repository to Active. Creation always requests private visibility.

Names contain 1-180 characters. A new repository slug contains lowercase letters, digits, and hyphens, beginning with a letter or digit. Bundle-import slugs may also contain underscores. The server limit is 100 characters. Descriptions are limited to 16 KiB.

Clone, fetch, and push over HTTPS.

The Clone dialog displays the authoritative URL. Its shape is:

git clone https://<organization-slug>.mozaic.space/git/<organization-slug>/<repository-slug>.git

# Connect an existing local repository
git remote add origin https://<organization-slug>.mozaic.space/git/<organization-slug>/<repository-slug>.git
git branch -M main
git push -u origin main

1. Issue a credential.For a private clone, select Git read. For push, select Git write as well; Mozaic automatically includes the matching read permission.
2. Authenticate.When Git prompts, use git as the username and the show-once mz_repo_... token as the password.
3. Verify the remote.Run git remote -v and then fetch or push. Do not put the token into the remote URL, a shell history entry, or a committed Git configuration file.

Import a verified Git bundle.

Import is a one-time transfer, not an ongoing mirror. Produce a bundle locally, then upload it through the Source, Details, and Review steps.

git bundle create repository.bundle --all
git bundle verify repository.bundle

1. Select the bundle.The file must be a valid Git bundle and must contain refs/heads/main.
2. Enter repository details.Provide the name, slug, and optional description. Imported repositories also start private.
3. Review and import.Mozaic streams the upload into quarantine, verifies it, and finalizes it atomically. Do not navigate away while the transfer is in progress.

Browse history and make bounded edits.

Files

Browse a selected revision, open UTF-8 source, inspect directories, history and blame, and use browser editing when the repository is Active and you hold Manage source.

Commits

Select a full branch or tag reference, page through its history, and inspect commit signature evidence.

Compare

Choose exact base and head references. The result records the resolved revisions and displays the textual patch.

Pull requests

Open or review a proposal whose source, target, and merge base are pinned into an immutable snapshot.

Browser edits compare the expected revision before updating a ref. If another writer moves the branch first, reload the latest revision and reapply the change instead of overwriting it.

Fork into an explicit organization and project.

1. Choose the target.Select an organization and project where you have Manage source. There is no hidden personal fork namespace.
2. Review repository details.Mozaic suggests a fork name and slug. Change them if the target project already uses that slug.
3. Confirm the source relationship.The Review step names the source repository, target owner, slug, and initial private access.
4. Create the fork.Wait for the new repository to become Active, create a branch, push your change, and then open a pull request against the original repository.

Forking is also the supported contribution path from a public repository: authenticate, place the fork in an organization you control, and keep ownership visible throughout review.

Issue the least privilege required.

Credential creation requires a fresh authentication window. A member can issue read-only credentials for their own use. A credential containing either write scope additionally requires Manage source.

git_read

Clone and fetch Git objects.

git_write

Push Git refs. This scope is valid only together with git_read.

lfs_read

Download Git LFS objects.

lfs_write

Upload LFS objects and create or release LFS locks. This scope is valid only with lfs_read.

1. Name the client.Use a recognizable name such as Work laptop or Release workstation.
2. Choose scopes and expiry.The default is 90 days. The accepted range is 1-365 days.
3. Copy the token immediately.The raw secret is returned once. Mozaic stores its digest, not a retrievable copy.
4. Revoke unused credentials.The list shows active, expired, and revoked credentials plus last-use time when available.

Archive before you delete.

Active

Readable and writable, subject to credentials, claims, and branch policy.

Archived

Read-only. Browse, clone, fetch, existing reviews, and verified bundle export remain available. Push, browser edits, review mutations, and write credentials are rejected.

Deleted

Repository bytes are removed. Identity, actor, reason, and lifecycle history remain as an audit tombstone.

1. Export first.Choose Export all refs to download a verified Git bundle independent of archive state.
2. Archive.This is reversible. Confirm that expected clones can still fetch and that automation no longer needs to push.
3. Reactivate if needed.An Archived repository can return to Active without changing its identity.
4. Delete only when required.Enter an audited reason and type the repository slug exactly. Byte deletion is permanent; the tombstone is not.

Public access has three gates

Anonymous repository reads require an explicitly public organization, an explicitly published project, and a public repository. A public child never makes a private parent public. New repositories and imports begin private.

Know the enforced boundaries.

• Keep tokens out of URLs, commits, logs, screenshots, and issue descriptions.
• Use separate credentials for separate devices or automation so each can be revoked independently.
• A push is checked against the exact target ref and branch policy; a valid write token does not bypass review rules.
• Repository operation history and description revisions are retained even when current prose or bytes change.

Resolve common failures.