Standard git, from any editor, zero plugin.

Create a repository

A repo has a slug, a protected default branch, and a visibility of private, internal, or public. Secret scanning is on from the first push — you don’t turn it on.

# Create a repo (default branch seeded protected + secret-scanned).
tilldev forge repos create --name acme-api \
  --slug acme-api \
  --visibility private        # private | internal | public
tilldev forge repos ls
tilldev forge repos get acme-api
#   clone   https://git.tilldev.dev/<org>/acme-api.git
#   ssh     ssh://git@git.tilldev.dev:2222/<org>/acme-api.git
#   status  active (empty — push a first commit)

Repos are also created for you on first push: if you push to a repo path that doesn’t exist yet and you’re authorized, TillForge seeds it with a protected default branch so the very first commit is already covered.

A new repo has no commits until someone pushes. It still clones (git warns that the repository is empty), forge refs says it is empty, and the dashboard shows how to make the first push. Nothing about an empty repo is an error.

The clone URL shapes

Two remote shapes reach the same repo. The git server is its own host, separate from the dashboard: git.tilldev.dev in the primary region, and a host of its own in each other data region. The repository page, tilldev forge repos get and the API’s clone_url give the right one. If the dashboard can’t be reached, clones and pushes keep working for up to 72 hours (see When the dashboard is down).

Clone and push over HTTPS

The tfp_ token is your password. Any git client will prompt for it; a credential helper can cache it. Read scope clones and fetches; write scope pushes.

# HTTPS — the token is the password. Works in every editor.
git clone https://git.tilldev.dev/<org>/<repo>.git
#   Username: your TillDev email  (or the literal 'x-access-token')
#   Password: a tfp_ token with read (clone) or write (push) scope

# First push of a brand-new local repo:
git init -b main
git remote add origin https://git.tilldev.dev/<org>/<repo>.git
git add . && git commit -m "first commit"
git push -u origin main

Clone and push over SSH

Register a public key, then use the ssh:// remote. The same push arrives at the same boundary — secret-reject, branch policy, and commit-identity checks all apply identically, whichever transport you use. Keys are fingerprinted, scoped, and expire by policy (no long-lived keys); manage them under Access & tokens.

# SSH — register a public key first (keys expire by policy).
tilldev forge keys add <repo> --name laptop \
  --key "ssh-ed25519 AAAA… you@host" --scope write --expires 90

git clone ssh://git@git.tilldev.dev:2222/<org>/<repo>.git
git push origin main

Clone only what you need

A large repository, or a CI job that needs one commit, doesn’t have to download every version of every file. Partial, sparse and shallow clones work over HTTPS and SSH with plain git.

# Partial clone: full history; file contents arrive as you check them out.
git clone --filter=blob:none https://git.tilldev.dev/<org>/<repo>.git

# Add sparse checkout to fetch only the directories you work in.
git clone --filter=blob:none --sparse https://git.tilldev.dev/<org>/<repo>.git
cd <repo> && git sparse-checkout set services/api

# Leave files over 1 MB on the server until something needs them.
git clone --filter=blob:limit=1m https://git.tilldev.dev/<org>/<repo>.git

# CI: one commit of one branch.
git clone --depth 1 --single-branch --branch main https://git.tilldev.dev/<org>/<repo>.git

# CI with the token in a credential helper (git 2.46+): send it with the
# first request instead of waiting to be asked.
git -c http.proactiveAuth=basic clone https://git.tilldev.dev/<org>/<repo>.git

# The CLI does both: token from its helper, sent up front.
tilldev forge clone <org>/<repo> --filter blob:none --sparse

After a push the repository is repacked in the background, so a clone streams stored data rather than recompressing history first.

Big files in Git LFS

Every repository takes Git LFS with no setup. Git LFS keeps a large file’s contents out of git history and stores them beside the repository, so a clone downloads only the versions it checks out. Pushes that add a file over the repository’s file size limit (100 MiB unless changed) are refused with the commands to move it here.

# Once per machine.
git lfs install

# Keep matching files in Git LFS from now on (commit .gitattributes).
git lfs track "*.psd" "assets/video/**"
git add .gitattributes && git commit -m "Track design files in Git LFS"

# Already committed a big file you haven't pushed? Move it, then push.
git lfs migrate import --include="assets/film.mp4"

# SSH remote: Git LFS talks HTTPS, so name the endpoint once.
git config lfs.url https://git.tilldev.dev/<org>/<repo>.git/info/lfs

• Same access. Git LFS uses the same tfp_ token as git over HTTPS: read scope downloads, write scope uploads.
• Checked on the way in. Each upload is hashed and refused if it doesn’t match the object it claims to be. One object can be up to 2 GiB.
• Backed up with the repository. Each repository’s LFS objects are backed up beside its history, sealed under your organization’s key, and every verification checks each object against its hash.
• File locking (git lfs lock) isn’t available.

Browse code, history, and blame

You don’t have to clone to read. The CLI and dashboard expose the tree, file contents, commit log, refs, and line-level blame — every --rev is resolved to a commit before anything runs.

# Browse without cloning — the same reads the dashboard uses.
tilldev forge tree acme-api --rev main --path src
tilldev forge blob acme-api --path src/index.ts --rev main
tilldev forge log  acme-api --rev main --limit 20
tilldev forge refs acme-api                 # branches + tags
tilldev forge blame acme-api --path src/index.ts

The dashboard renders the same reads as a repo browser: file tree, README, the commit graph, refs, and blame — plus the open PRs, live findings, and crash correlation for the repo.

Edit in the browser

With write access you can change files without cloning. In the Code tab, Edit changes the file you are viewing and commits it. ✎ Editor opens the web editor, where you change, create or delete several files and commit them together as one commit.

Commits from the browser are checked like a push: a commit containing a secret is refused, and the branch’s protection applies. If the branch requires reviews or checks, the editor commits to a new branch and opens a pull request. Press ⌘S or Ctrl-S to commit.

When the dashboard is down

The git server decides who may clone or push by asking the dashboard. It also keeps a signed copy of who can reach each repository, every branch’s protection, each repository’s commit-identity mode and file size limit, and each person’s commit addresses, updated whenever a token, key, collaborator, member, repository grant, commit email, policy or repository setting changes. The copy is signed with Ed25519 and ML-DSA-65 and both signatures must check, so a server that has been tampered with still can’t give itself access.

If the dashboard can’t be reached:

• Clones, fetches and pushes keep working for up to 72 hours from the copy’s last update, with the tokens, deploy tokens and SSH keys that existed then, and the same access rules.
• Every push is checked against branch protection, commit identity and the file size limit as they stood then. If the server has no usable copy, it refuses the push rather than skip the check.
• A push that lands is kept in the ref log for recovery, and its CI, webhooks, deployments and secret findings are delivered when the dashboard is back, with the time of the push.

What doesn’t work until it is back:

• Creating a repository by pushing to a new name.
• Tokens and keys created after the copy’s last update.
• The first push of an organization that has never pushed, and every repository if the git server’s machine restarts during the outage: repository encryption keys come from the dashboard. They answer 503, locked, until it is back.
• Anything at all once the copy is more than 72 hours old.

Where your repositories are stored

Each organization picks a data region. Repositories created from then on are stored on git servers in that region, and stay there: changing the region moves where new repositories go, not the ones you already have. Owners set it under TillForge → Data region, with tilldev forge region set <region>, or with PUT /api/forge/region. Every change is in the audit log.

tilldev forge region                    # where new repos go, their git host, where existing ones are
tilldev forge region set eu-central     # owner: new repos go there; existing ones stay
tilldev forge setup-git                 # git authenticates every TillForge host
tilldev forge ci runners register --name eu-1 --region eu-central

• Its own host. Each region has its own git host. Cloning or pushing through another region’s host sends git on to the right one, for anyone who may reach the repository. Run tilldev forge setup-git again after your organization starts using a new region, so git authenticates its host too.
• Forks. A fork stays with the repository it came from, so forking a repository stored in another region than your organization’s is refused.
• Keys. A git server is given your repository key only if it holds your repositories or serves your region, and only from its own addresses.
• CI. Jobs run wherever your runners run. Register a runner with --region and it takes jobs only for repositories stored there.
• Passing through. Code you open in the dashboard, or send to an AI feature your egress policy allows, passes through TillDev’s servers on its way to you or the model. It isn’t kept there.