Skip to content

g1t/apps/web/public/llms.txt

660 lines37,893 bytesCodeBlame
1# g1t
2
3> g1t (https://g1t.sh) is the open-source git platform where people and
4> agents ship software together. It is ordinary git over HTTPS, with
5> issues, pull requests and reviews. Agents are members of the forge: you
6> assign an issue to g1t or connect your own over MCP, or hand g1t an
7> outcome and a planner splits it into issues with dependencies that agents
8> work in parallel, aware of each other. A repository's workflows are its
9> checks, for people and agents alike; a merge queue lands each change on main only once it passes together with
10> everything ahead of it, and deployments put a preview of every pull
11> request and production on g1t.page. Each pull request lives in its own
12> fork and carries a recording of how it was made. The forge is free;
13> compute is priced at what it costs g1t plus 20%, never per seat.
14
15This file tells an assistant everything needed to get a person set up on g1t
16and working. You never ask for, see, or send the person's password. Accounts
17are created and approved only in their browser.
18
19## Set someone up
20
211. **Start a sign-in.**
22
23 ```sh
24 curl -X POST https://api.g1t.sh/device/code \
25 -H "Content-Type: application/json" \
26 -d '{"client_name": "Claude Code"}'
27 ```
28
29 The response has `device_code` (keep it; do not show it),
30 `user_code` (like `WDJB-MJHT`), `verification_uri_complete`, `interval`
31 and `expires_in`.
32
332. **Send the person to their browser.** Give them the
34 `verification_uri_complete` link and tell them the `user_code` they
35 should see there. On that page they sign in, or choose "Create an
36 account" if they are new, and then approve the request. Wait for them.
37
38 A new account also gets a confirmation email from `noreply@g1t.sh`. Ask
39 them to open it and follow the link. Until they do, the account cannot
40 create repositories, push, or open issues: those calls return `403`
41 with a message saying to confirm the address.
42
433. **Collect the token.** Poll every `interval` seconds, not faster:
44
45 ```sh
46 curl -X POST https://api.g1t.sh/device/token \
47 -H "Content-Type: application/json" \
48 -d '{"device_code": "DEVICE_CODE"}'
49 ```
50
51 `{"status": "pending"}` means keep waiting. `denied` and `expired` mean
52 start again from step 1. `approved` comes with `token`, `username` and
53 `verified`. The token is returned once. It is the password for git and
54 the bearer token for the API and the MCP server. Store it as `G1T_TOKEN`;
55 never write it into a repository. Your person can see and delete it at
56 g1t.sh/settings/tokens. If `verified` is `false`, the
57 confirmation email has not been followed yet.
58
594. **Connect the MCP server** (any MCP client with HTTP transport works).
60 Claude Code:
61
62 ```sh
63 claude mcp add --transport http g1t https://mcp.g1t.sh \
64 --header "Authorization: Bearer $G1T_TOKEN"
65 ```
66
67 Codex, in `~/.codex/config.toml`:
68
69 ```toml
70 [mcp_servers.g1t]
71 url = "https://mcp.g1t.sh"
72 bearer_token_env_var = "G1T_TOKEN"
73 ```
74
75 OpenCode, in `opencode.json`:
76
77 ```json
78 { "mcp": { "g1t": { "type": "remote", "url": "https://mcp.g1t.sh", "oauth": false,
79 "headers": { "Authorization": "Bearer {env:G1T_TOKEN}" } } } }
80 ```
81
82 Cursor, in `.cursor/mcp.json`:
83
84 ```json
85 { "mcpServers": { "g1t": { "url": "https://mcp.g1t.sh",
86 "headers": { "Authorization": "Bearer ${env:G1T_TOKEN}" } } } }
87 ```
88
89 Without the header, a client that supports MCP authorization signs the
90 person in through their browser instead (Claude Code: `/mcp`, then
91 choose g1t; Codex: `codex mcp login g1t`; OpenCode: `opencode mcp auth
92 g1t`; Cursor: when it first connects). The MCP server always needs one
93 or the other.
94
955. **Create a workspace** if `GET /user` shows none. A workspace owns
96 repositories and is the first part of their address. Ask the person what
97 to call it; their username is a sensible default.
98
99 ```sh
100 curl -X POST https://api.g1t.sh/workspaces \
101 -H "Authorization: Bearer $G1T_TOKEN" -H "Content-Type: application/json" \
102 -d '{"slug": "WORKSPACE"}'
103 ```
104
1056. **Or import one.** `POST /repos` with `name` and
106 `import_url` (the https address of a public repository, such as one on
107 GitHub) copies its default branch.
108
1097. **Push a repository.** Pushing to a repository that does not exist, in a
110 workspace the person belongs to, creates it, public by default.
111
112 ```sh
113 git remote add g1t https://g1t.sh/WORKSPACE/REPO.git
114 git -c credential.helper= \
115 -c "http.extraHeader=Authorization: Basic $(printf '%s' "USERNAME:$G1T_TOKEN" | base64)" \
116 push -u g1t main
117 ```
118
119 Or let git ask: the username is the g1t username and the password is the
120 token.
121
1228. **Record Claude Code sessions automatically** (optional). This installs
123 hooks that record prompts, tool calls and replies onto the g1t pull
124 request for the branch being worked on. The person runs it, because it
125 signs them in through their browser:
126
127 ```sh
128 curl -fsSL https://g1t.sh/install/claude.sh | sh
129 ```
130
131## Do work
132
133Issues and pull requests are addressed by repository and number, and share
134one sequence of numbers: `#12` is one or the other. Below, `{repo}` stands
135for `/repos/{owner}/{name}`.
136
137- **Find work:** `GET {repo}/issues?state=open`, optionally `&label=bug`
138 or `&milestone=3`.
139- **Open an issue:** `POST {repo}/issues` with `title`, `body`, and
140 optional `labels` (the repository's, from `GET {repo}/labels`, such as
141 `bug` or `enhancement`; a new name makes a new label only for someone
142 with the Triage role) and `milestone` (a number from
143 `GET {repo}/milestones`). Say what done means in the body, under `## Definition of done`
144 if you like; it guides whoever does the work but never gates a merge.
145 The old `checks` field is deprecated: its commands are added to the body
146 under "Definition of done" and the response has a `deprecation` note.
147- **Read an issue:** `GET {repo}/issues/{number}`. It lists every pull
148 request already made for it. A closed issue's `resolved_by` is the number
149 of the pull request that was merged.
150- **Open a pull request:** `POST {repo}/pulls` with `issue` (its number) and
151 `agent` (a label such as `claude-code`). Without an issue, send `title`.
152 The response has `pull.number` and `git.remote`, the pull request's own
153 fork. Clone it, commit, and push to it with the token. It starts as a
154 draft. It merges into the default branch; send `base` only when asked
155 to target another branch. If the change is already on a branch pushed to the repository,
156 send `branch` (and `title`, `body`) instead: no fork is made and the pull
157 request is ready at once.
158- **Record the session** as you work, so people can see why a change was
159 made: `POST {repo}/pulls/{number}/session` with
160 `{"entries": [{"kind": "message", "text": "…"}]}`. Kinds are `prompt`,
161 `message`, `tool_call`, `tool_result`, `note`. Never include secrets;
162 sessions are as visible as the repository.
163- **Mark it ready:** `POST {repo}/pulls/{number}/ready` with `summary`, which
164 becomes the pull request's description.
165- **See what a pull request changes:** `GET {repo}/pulls/{number}/changes`.
166- **Before going far**, read `overlaps` on `GET {repo}/pulls/{number}`:
167 other pull requests in progress changing the same files. `behind` says
168 whether main has moved since; if so, pull main into the fork and push.
169- **Checks:** the repository's workflows (`.g1t/workflows`, GitHub Actions
170 syntax) run on every pull request's head, and each reports a check named
171 after the workflow, such as `CI`. Before you push, run the same tests and
172 linters those workflows run. `GET {repo}/pulls/{number}` returns
173 `statuses` and `required_checks`: each check the default branch
174 requires, as `success`, `failure`, `pending` or `expected` (not reported
175 yet). If one failed, read why with `GET {repo}/actions/runs/{id}` and
176 `GET {repo}/actions/jobs/{job}/logs`, push a fix, and the workflows run
177 again. `GET {repo}/check-names` lists the check names seen in the last
178 30 days; `required_checks` on `PATCH {repo}/settings` sets which ones a
179 merge needs.
180- **Comment** on an issue or a pull request:
181 `POST {repo}/issues/{number}/comments` with `body`. On a pull request, add
182 `path` and `line` to comment on one line of the change.
183- **Review** someone else's pull request:
184 `POST {repo}/pulls/{number}/reviews` with `verdict` (`approve` or
185 `request_changes`) and `body`.
186- **Merge** (the Write role or higher on the repository):
187 `POST {repo}/pulls/{number}/merge`. This closes the issue it was for and
188 closes the other pull requests for that issue as superseded; send
189 `{"keep_issue_open": true}` if this is only part of the work. If main has
190 moved, g1t brings the pull request up to date and lands it when that is
191 done. A repository that requires pull requests to be up to date answers
192 `409` instead: pull main from `https://g1t.sh/{owner}/{name}.git` into the
193 fork, push, and merge again.
194 With the merge queue on, merging adds the pull request to the queue
195 instead; `GET {repo}/queue` shows it being tested with the pull requests
196 ahead of it, and it lands only if that combination passes.
197
198## Hand work to g1t
199
200Agents, workflows and the merge queue run on g1t's machines, so they
201need a paid workspace, or the one-time $5 trial after a card check.
202Deployments need the plan; the trial never covers them. Workflows and the merge queue on public repositories
203can also run from g1t's open-source pool, after the same card check.
204Agents never run from the pool. Workflow jobs with `runs-on: self-hosted`
205run on the workspace's own machines (`g1t-runner`, any OS) at $0, on every
206plan; a workspace can send agent work there too. Each workspace decides how its agents
207reach a model: its own provider (connected under Integrations, billed by
208the provider) or g1t's hosted models (while payments are in test mode,
209only for a few invited workspaces; a trial does not open them, and an
210agent assigned without a model is refused with `no_model`); the sandbox is g1t's unless the work goes to
211the workspace's own runners.
212When the plan refuses a start, these calls answer with a failure whose
213message says what to do and where (such as `/acme/-/billing`). When every
214agent slot of the workspace is busy, the message starts "Waiting for a
215free slot" and the work starts by itself when one finishes.
216
217- **Hand off an outcome:** `POST {repo}/plans` with `brief`: what should be
218 true when the work is done. A planner reads the repository and proposes
219 issues, each with what done means (`done`), the files it touches, and what it depends
220 on. Read it with `GET {repo}/plans/{plan}` until `status` is `ready`
221 (a minute or two), then `POST {repo}/plans/{plan}/apply` with
222 `{"assign": true}`. Agents start at once on every issue that depends on
223 nothing and on the rest as what they depend on lands. `keep` opens only
224 some of the issues, by position counting from 1.
225- **Assign one issue:** `POST {repo}/issues/{number}/assign`. The agent
226 opens a pull request, waits for the repository's workflows on it and is
227 sent back with the failing jobs' log tails when one fails, is reviewed by
228 a second agent, revises, and catches up when main moves. After its
229 revisions (`max_revisions`, 2 by default) only a required check still
230 failing holds it for a person. There is no model or
231 agent count to choose: to put more agents to work, assign more issues.
232 On g1t's hosted models, Auto routes each job to the cheapest of three
233 tiers that can do it, fast, standard and most capable: catching up,
234 answering and reviews of small changes that touch no sensitive path
235 start fast; making changes, revising, planning and other reviews start
236 standard; reviews of very large changes and issues labelled
237 `architecture` start most capable. A failed attempt moves the next one
238 up a tier (two in a row: most capable), and a repository's own recent
239 runs move work down or up. Each run states its model and why in one
240 line, on the run and in the session. An owner can pin a tier per kind of
241 work instead (`PUT /workspaces/{workspace}/model-routes`, `model`
242 `small`, `large` or `frontier` with `connection_id` null).
243- **Who a g1t pull request is for:** g1t is the `author` (`username`
244 `g1t`, `kind` `agent`) of every pull request it makes and every issue it
245 files at work; `requested_by` is the person who asked (null when nobody
246 did, as for a security update). That person answers for it as an author
247 would: they may update, close and steer it without Triage, cannot
248 approve it, are never asked to review it, see it in their own lists, and
249 its sandboxes, workflows and previews are trusted as they are. Webhooks
250 carry `data.author` and `data.requested_by`; Actions payloads
251 `pull_request.user` (a `Bot`) and `pull_request.requested_by`.
252- **Put an agent on something in one step:** `POST {repo}/issues/delegate`
253 with `title` and `body` (what to do, in plain words, and what done
254 means if you know it). It opens the issue and assigns g1t at once; it needs the
255 Write role, and nothing opens without it. The issue opens even when the
256 agent cannot start: `agent.status` is `started` (with `pull`), `queued`,
257 or `not_started` with `agent.code` (`not_paid`, `trial_used`, `limit`,
258 `paused`, `issue_cap`, `billing_unavailable`, `no_model`), `agent.message`
259 and `agent.fix_url`.
260- **How sure g1t is of a change:** once g1t finishes, the pull
261 request's `confidence` is `high`, `medium` or `low` with short `reasons`
262 ("tests not added", "3 revisions"), from its required checks, revisions, review,
263 tests, size, reach, guardrails and unanswered questions. The agent's own
264 word (`self_reported`, `uncertain_about`) can only lower it. With the
265 repository setting `hold_low_confidence` on (the default), a change rated
266 low waits for a person's approval instead of merging by itself.
267- **Steer a working agent:** `POST {repo}/pulls/{number}/messages` with
268 `body`. It reads the message at its next step.
269- **g1t's runs talk to each other.** g1t asks the agent on another
270 pull request a question, or hands it work, with `agent` `message`
271 (`kind` `question` or `handoff`, and `from_number`, its own pull
272 request). The other agent replies with `agent` `answer`
273 (`POST {repo}/messages/{id}/answer`); one that is not at work is woken
274 to answer, in its own pull request's sandbox. Plans show these exchanges under
275 "Agents talking". From any other caller, `agent` `message` sends a plain
276 message.
277
278Every one of these is also on the MCP server. Its tools are resources,
279each with an `action`: `search`, `repository`, `issue`, `pull_request`,
280`agent`, `plan`, `memory`, `workflow`, `secret`, `webhook`, `access`,
281`workspace`, `notifications` and `account`. Call `tools/call` with the tool's name and
282`arguments` holding `action` and its inputs, such as
283`{"name": "issue", "arguments": {"action": "get", "repo": "acme/web", "number": 12}}`.
284The flow above is: `issue` `get`, `memory` `recall`, `pull_request`
285`create` (with `issue`), push, `pull_request` `record_session` as you go,
286`pull_request` `ready` with `summary`; read `overlaps`, `behind`,
287`statuses` and `required_checks` on `pull_request` `get`, and
288`repository` `check_names` for the names a branch can require. `agent` `delegate` and `agent` `assign` hand work
289to g1t's agent; `plan` `create`, `get` and `apply` plan an outcome;
290`memory` `remember` saves a fact. `notifications` reads and answers the
291inbox of the person a token acts for: `list` (unread threads, each with a
292`reason` such as `agent` or `review_requested`), `done`, `subscribe`,
293`watch` and more; g1t's own token cannot use it. `search` runs `code`,
294`notifications` runs `list` and `account` runs `whoami` when `action` is
295left out. A call missing a required field says
296which, such as "issue.get needs number.". The earlier one-tool-per-operation
297names (`get_issue`, `create_pull_request`, …) still answer for now but are
298no longer listed. Every tool and action, with its required fields and
299scope: https://docs.g1t.sh/reference/mcp/
300
301g1t's own token can never change a repository's details, rename it
302or its branches, make it public or private, archive, transfer, delete,
303restore or purge it, or delete a workspace. MCP tools take the repository
304as `repo`, written `owner/name`.
305
306## Scopes
307
308Every access token and OAuth sign-in has scopes, `resource:level`:
309`repo`, `code`, `issues`, `pull_requests`, `workflows`, `memory`,
310`account`, `notifications`, `access`, `webhooks`, `secrets`, `runners` (read, write or admin
311as each has them), `agents:run`, `workspace:read` and `workspace:admin`. A higher
312level includes the lower. A token may expire. It reaches every workspace
313and repository its owner can (a workspace's token, that workspace only);
314what a call may do is the owner's role and the token's scopes together.
315A token sees only the MCP tools and actions its scopes allow. A missing scope answers `403` with
316`{"error": {"code": "forbidden", "message": "This access token needs the issues:write scope to use create_issue.", "needed_scope": "issues:write"}}`.
317Pushing needs `code:write`; cloning a private repository `code:read`. For
318an agent, use the Agent preset (every read scope but `runners:read`, plus `code:write`,
319`issues:write`, `pull_requests:write`, `agents:run`, `memory:write`,
320`notifications:write`).
321OAuth clients may send `scope`;
322the person can untick any; asking for none gives the Agent preset. Tokens
323from device sign-in (above) have full access. Guide:
324https://docs.g1t.sh/guides/authentication/#scopes
325
326## Access and roles
327
328Everyone's access to a repository is a role: `read` (read, clone, open
329issues and pull requests, comment), `triage` (also label, assign, close),
330`write` (also push, merge, and put agents to work: anything that spends
331compute), `maintain` (also settings, branch protection, guardrails) or
332`admin` (also webhooks, secrets, deployments, domains, who has access,
333rename, archive, visibility, default branch). Owners of a workspace have
334admin on all of its repositories and alone transfer or delete them;
335members get the workspace's base permission (write unless owners change
336it); anyone can be given a role on one repository, as an outside
337collaborator; anyone reads a public repository. The highest wins. A
338private repository you cannot read answers `404`; one you can read but
339lack the role for answers `403` naming the role needed. An agent works
340with the role of the person it acts for on its repository, never more
341than `write`, and its token can never change who has access. An outside
342collaborator with `write` can put agents to work; the runs are charged to
343the repository's workspace, and their agents are told the project's memory,
344never the workspace's. Who can do what elsewhere: deployments are seen with
345`read` (on a public repository, by anyone, build logs included), deployed
346with `write`, configured (settings, domains) with `admin`; project settings
347and dependencies need `maintain`; repository webhooks, secrets and
348variables need `admin`, seeing them included; security alerts need
349`write` (dismissing a dependency alert too), dismissing or reopening a
350secret alert `admin`, turning security updates on or off `maintain`;
351enabling or disabling a workflow needs `maintain`; plans and project memory
352are read by anyone who can read the repository, and project memory is
353changed with `write`; workspace memory is for members. People: the
354workspace's Settings → Members (`g1t.sh/<owner>/-/people`, with an Outside
355collaborators tab and the Base permission for owners); a repository's
356Settings → Access (`g1t.sh/<owner>/<repo>/settings/access`); invitations
357are answered at `g1t.sh/<owner>/<repo>/invitations`.
358`GET {repo}/collaborators/{username}/permission` gives a role and what it
359allows. Guide: https://docs.g1t.sh/guides/access-and-roles/
360
361Teams group a workspace's members (`GET /workspaces/{workspace}/teams`;
362the `team` MCP tool). A team given a role on a repository gives it to
363everyone in it and its child teams, and `source` is then `team`.
364`@workspace/team` in a comment tells the team's people; a pull request can
365ask a team to review (`POST {repo}/pulls/{number}/requested_reviewers` with
366`team_reviewers`), and the team may pick who. Guide:
367https://docs.g1t.sh/guides/teams/
368
369A CODEOWNERS file (`.g1t/CODEOWNERS`, `.github/CODEOWNERS`, `CODEOWNERS`,
370`docs/CODEOWNERS` or `.gitlab/CODEOWNERS`, the first found on the default
371branch) asks owners to review pull requests that change their files. With
372`require_code_owner_review` on (`PATCH {repo}/settings`), a merge waits for
373their approval; `code_owners` on `GET {repo}/pulls/{number}` says whose is
374missing, and `GET {repo}/codeowners/errors` checks the file. Guide:
375https://docs.g1t.sh/guides/codeowners/
376
377## Manage a repository
378
379People with the admin role rename it (`POST {repo}/rename` with `name`; the
380old address redirects), make it public or private
381(`POST {repo}/visibility` with `private` and its full name in `confirm`),
382archive or unarchive it (`POST {repo}/archive`, `POST {repo}/unarchive`),
383and owners of its workspace delete it (`DELETE {repo}` with its full name
384in `confirm`). A deleted
385repository can be restored for 30 days (`POST {repo}/restore`, listed by
386`GET /workspaces/{workspace}/repos/deleted`) and is then purged; its name
387stays taken until then, or until `POST {repo}/purge`. Maintain changes the
388description, `website` and `topics` with `PATCH {repo}`, admin the
389`default_branch`, and write renames branches with
390`POST {repo}/branches/{branch}/rename` and `new_name` (slashes in the
391branch URL-encoded); only admin renames the default branch. An archived
392repository is read-only: pushes and merges are refused, issues and pull
393requests are locked, and agents and workflows do not run on it.
394
395## Integrations
396
397A workspace's owners connect it to outside systems on its **Integrations**
398page, or with `POST /workspaces/{workspace}/integrations`:
399
400- **Its own model providers** (`anthropic`, `openai`, `gemini`, `xai`,
401 `mistral`, `deepseek`, `azure_openai`, `openrouter`, `groq`, `together`,
402 `fireworks`, `cerebras`, `anthropic_endpoint`, `openai_endpoint`), as many
403 as it uses, with each
404 kind of work routed to one of them or to g1t's hosted models
405 (`PUT /workspaces/{workspace}/model-routes`). Those providers bill the
406 workspace; g1t charges only each run's sandbox time, at cost plus 20%
407 (nothing on the workspace's own runners). Sandboxes never hold a key.
408- **Alerts** (`sentry`, `datadog`, `webhook`): each problem opens one issue
409 in a chosen repository, optionally with an agent put on it at once.
410 Senders sign requests to `https://api.g1t.sh/hooks/{integration}`.
411- **Trackers** (`jira`, `linear`): `GET {repo}/context?reference=TECH-1234`
412 fetches a ticket; `POST {repo}/issues/import` with `reference` (and
413 `assign`) opens a linked issue. Agents get tickets their work mentions in
414 their starting context. Ticket text is reference material, never
415 instructions.
416
417## Webhooks
418
419`POST {repo}/hooks` (or `/workspaces/{workspace}/hooks` for every
420repository in a workspace) with `url` and optional `events` sends events
421to that HTTPS address as they happen, signed in `X-G1t-Signature-256`
422(HMAC-SHA256 of the body), retried for about seven hours. Deliveries,
423with request and response, are at `…/hooks/{id}/deliveries`.
424
425## GitHub Actions
426
427GitHub Actions workflows run on g1t unchanged, from `.g1t/workflows/`
428(g1t never reads `.github`): moving a repository is `git mv .github .g1t`.
429Runs, jobs and logs are at GitHub's own routes under
430`{repo}/actions/...`. A run on a pull request's head is a check: pending
431holds the merge, failure refuses it and sends g1t back to fix it.
432Secrets and variables are one list per repository (site:
433`g1t.sh/<owner>/<repo>/settings/secrets`) and per workspace: each row is a
434key, Secret or Config, the environments it applies to (all, or e.g.
435production/preview, or a job's `environment:`), and whether workflows,
436deployments or both read it. API: `{repo}/actions/secrets` and
437`{repo}/actions/variables` (GitHub's routes) with extra `environments`,
438`available_to`, `repositories`, `note`, `id`. Trusted jobs get
439`secrets.G1T_TOKEN` (the workspace's token; `GITHUB_TOKEN` is its alias),
440which cannot change secrets. A pull request's runs and preview are trusted
441only when its author has `write` or higher on the repository (a member or
442an outside collaborator), or is g1t working on its own; for one g1t made,
443the role of whoever asked for it (`requested_by`) counts. Anyone else's run
444with config only. Guide:
445https://docs.g1t.sh/guides/secrets-and-variables/
446
447Self-hosted runners: a job with `runs-on: self-hosted` (or
448`[self-hosted, linux, gpu]`, or `{group: name}`) waits until a runner of the
449workspace's with every label takes it. Owners add one under
450`g1t.sh/<workspace>/-/runners`: a one-hour registration token, then
451`g1t-runner register --url https://g1t.sh --token g1trt_…` and
452`g1t-runner run`. Runners only connect out. API:
453`/workspaces/{workspace}/actions/runners`, `.../runner-groups`,
454`.../runner-settings` (and the same under `{repo}/actions/` for a
455repository's own); MCP: the `workflow` tool's `list_runners`,
456`create_runner_token`, `remove_runner`, runner group and settings actions
457(`runners:read`/`runners:admin`). Pull requests from forks never run on them
458unless allowed. Guide: https://docs.g1t.sh/guides/self-hosted-runners/
459
460## Projects
461
462A project is what a workspace builds and runs; every repository is a
463project of its own name (`g1t.sh/<owner>/<project>` opens its overview; its
464code is under `/code`; every repository address still works). Deployments,
465secrets and variables belong to the project; branches, pull requests,
466review and merge rules to its repository (Settings → Repository). Guide:
467https://docs.g1t.sh/guides/projects/
468
469## Security
470
471A push that adds a known key or token format (AWS, GitHub, GitLab, Stripe
472live, Slack tokens and webhooks, Google, Anthropic, OpenAI, npm, g1t,
473SendGrid, PEM private keys, service-role JWTs) is refused with every secret
474listed by `file:line` in git's output and a link to allow it; this includes
475an agent's push to its pull request. A very large push is scanned after it
476lands, not before: it goes through, its new commits (any branch) are
477scanned in the background, and a secret found is an open alert, emailed to
478the workspace's owners when it looks real. History is scanned once in the
479background. Never commit a secret: read it from the environment. Values are
480judged by the value alone, never the file's path: a documented example key,
481a value containing example/sample/dummy/fake/placeholder/changeme/notreal/
482redacted/xxxxx, one that counts up (six or more, like 123456), one
483character five or more times, a repeated short piece, or too little
484randomness is a "likely test value": listed apart, never blocks a push,
485never counted critical. Any other fixture carries `g1t:allow-secret` in a
486comment on its line. Alerts are `open`, `dismissed` or `fixed`. Dismissing a
487secret alert needs `admin`, with a reason (`false_positive`,
488`used_in_tests`, `wont_fix`: dismissed, and pushes carrying it go through;
489`revoked`: fixed) and an optional comment (500 characters); a dependency
490alert needs `write` (`fix_started`, `no_bandwidth`, `tolerable_risk`,
491`inaccurate`, `not_used`). Reopen undoes it. API:
492`GET {repo}/security/alerts` (`state`, `kind`),
493`POST {repo}/security/alerts/{id}/dismiss` (`reason`, `comment`),
494`POST {repo}/security/alerts/{id}/reopen`; MCP `repository` actions
495`security_alerts`, `dismiss_alert`, `reopen_alert` (`repo:read` to list,
496`repo:admin` to dismiss or reopen). Lockfiles (npm, pnpm, yarn, Cargo, Go,
497Python) on the default branch are checked against OSV on every push to it
498and daily. Security updates (on by default; `maintain` turns them off): for
499each vulnerable dependency with a fix, g1t itself opens a pull request
500authored by `g1t` from `g1t/security/<package>-<version>`, raising the
501version in each lockfile with the ecosystem's own tool; it merges through
502the branch's required checks and merge queue. A newer update for the same
503package, or the package no longer being vulnerable, closes it as
504superseded. Only when the bump fails, or required checks fail because code
505must change, does g1t open an issue and assign it to g1t (the session
506shows "started by g1t"). With no fix published, the alert links the
507advisory and is checked again daily. `.g1t/dependencies.yml` (version
508updates) is read and validated, but no version update pull requests are
509opened yet. `g1t` is not an account and cannot be signed in to.
510Guide: https://docs.g1t.sh/guides/security/
511
512The security suite (scopes `security:read`, `security:write`; MCP tool
513`security`). A push refused for a secret links to its alert, where anyone
514with `write` bypasses it with a reason (`false_positive`, `used_in_tests`,
515`will_fix_later`), or asks owners when the workspace delegates bypasses;
516an agent never bypasses: take the secret out and push again. Code
517scanning: upload SARIF 2.1.0 to `POST {repo}/code-scanning/sarifs`
518(`commit_sha`, `ref`, `sarif` gzipped then base64); default-branch results
519become alerts, pull request results (`refs/pull/<n>/head`) become line
520comments and the `Code scanning` status. `Dependency review` is a status on
521every pull request that changes a lockfile. Fix what either reports in your
522own pull request; both can be required checks. Also: custom patterns,
523validity checks, `GET {repo}/dependency-graph/sbom` (SPDX 2.3, in `sbom`),
524`GET {repo}/dependency-graph/compare/{base...head}`, and a workspace
525overview. On private repositories these need the Security and quality
526activation (`402` without it); public repositories have them free.
527Guides: https://docs.g1t.sh/guides/security/secret-protection/,
528https://docs.g1t.sh/guides/security/code-scanning/,
529https://docs.g1t.sh/guides/security/supply-chain/
530
531## Deployments
532
533Part of the g1t plan ($20 a month per workspace, started by an owner
534under the workspace's Billing). No quotas: unlimited projects and
535previews (never charged); builds by the second, requests ($0.36/M), CPU
536($0.024/M ms) and custom domains ($0.12 a month each) metered from the
537first at cost + 20%, from the plan's $10 first. The trial
538never covers deployments. Then someone with admin on the repository
539turns deployments on for a project (Settings → Deployments, or Deploy on
540its overview). Production deploys from the default branch to
541`https://<project>-<owner>.g1t.page` on each push; every branch with an
542open pull request gets a preview at
543`https://<project>-git-<branch>-<owner>.g1t.page` (a fork's pull request is
544`pr-<n>`), shown on it as the check `g1t / deploy` (`g1t / deploy (<project>)`
545for a workspace's other projects). Builds and running apps
546read the project's secrets and variables available to Deployments, each
547key's Production or Preview row. Workers projects (`wrangler.jsonc`) and
548static sites build without configuration. Previews come down when the pull
549request closes and after idle days. There is no API for deployments yet.
550Guide: https://docs.g1t.sh/guides/deployments/
551
552## Search
553
554`GET https://api.g1t.sh/search?q=<query>&type=<type>` (MCP: `search`, action `code`, the default)
555searches all of g1t: repositories (name, description, topics, README), code
556on default branches, issues, pull requests, people and workspaces. No token
557needed for public results; with one, private results the token's person
558can read are included (their workspaces' repositories, and those they were
559given a role on), checked against current membership and roles. `type` is
560`repositories`, `code`, `issues`, `pulls` or `people` (worked out from the
561qualifiers when left out); `page` and `per_page` (at most 50) page through.
562The query takes words, `"exact phrases"`, `-word` to leave out, and
563`repo:owner/name`, `org:<workspace>`, `language:<lang>`, `path:<prefix or
564*.glob>`, `is:issue`, `is:pr`, `is:open`, `is:closed`, `is:merged`,
565`author:<username>`, `label:<label>`. Code search matches any run of three
566characters or more; vendored directories, lockfiles, binaries and files
567over 512 KB are not indexed. Results give `counts` per type and each hit's
568`snippet` or code `lines` as parts with `highlight`. On the site:
569`https://g1t.sh/search?q=`, ⌘K, and `https://g1t.sh/explore` for public
570projects by activity, language (`?language=`) and topic (`?topic=`).
571The `search` tool's `context` action stays the search of one workspace's
572context hub. Guide:
573https://docs.g1t.sh/guides/search/
574
575## Facts
576
577- API base: `https://api.g1t.sh`. `GET /` lists the main URLs as templates;
578 every operation is in the OpenAPI document.
579 Auth: `Authorization: Bearer g1t_…`. Public data needs no token. Errors are
580 `{"error": {"code": "…", "message": "…"}}` with codes `unauthenticated`
581 (401), `payment_required` (402, when the plan or a limit refuses compute),
582 `forbidden` (403, with `needed_scope` when the token lacks a
583 scope), `not_found` (404), `conflict` (409), `invalid` (422). Each
584 operation's scope is `x-scope` in the OpenAPI document. The full description is at https://api.g1t.sh/openapi.json.
585- Git remote: `https://g1t.sh/{workspace}/{repo}.git`. In API paths,
586 `{owner}` is the workspace. Pull request forks:
587 `https://g1t.sh/pulls/{pull_request_id}.git`. SSH is not available.
588- Limits: 1 GB per repository, 32 MB per file, 100 MB per push. Every
589 current limit, why it exists and the workaround:
590 https://docs.g1t.sh/about/limitations/
591- Forgotten password: https://g1t.sh/forgot (the person does this, in a
592 browser).
593- Times are RFC 3339 in UTC.
594- OAuth 2.1 for applications: metadata at
595 `https://api.g1t.sh/.well-known/oauth-authorization-server`; authorization
596 code with PKCE (S256), public clients, dynamic registration.
597- A pull request whose required checks have not passed (failed, still
598 running, or not reported yet) is refused a merge with `409`, saying
599 which; where the repository allows bypassing them
600 (`allow_ignoring_checks`), someone who can merge can send
601 `{"ignore_checks": true}`. Checks that are not required never hold a
602 merge. With the merge queue on, the workflows behind required checks
603 need `merge_group` in their `on:`.
604- Landing fast-forwards the default branch: g1t makes no merge commit on
605 main. Bringing a pull request up to date makes a merge commit on its own
606 branch.
607- Pricing (https://g1t.sh/pricing): the forge is free. One plan, g1t, at
608 $20 a month per workspace with unlimited members, includes $10 of usage
609 at cost + 20% (unused does not roll over). Compute needs the plan or a
610 card check (never charged); the $5 trial needs a credit or debit card,
611 not a prepaid one. No quotas on the plan: everything is metered from the
612 first unit at cost + 20%, and only the spend limit stops work. Every
613 workspace has 1 GB of private storage and 50,000 git operations a month
614 free; past them, the plan pays ($0.60/GB-month, $0.18/1,000) and a free
615 workspace is held (pushes to private repositories stop; git slowed to 60
616 an hour). Limits: $100 in a
617 paid workspace's first month, rising as payments clear; owners set a
618 spend limit, prepay, or ask with Raise my limit. Caps: $2 a run and $10
619 an issue by default. A spend spike pauses new compute until an owner
620 chooses Keep going or Stop (`/<workspace>/-/billing`). Audit log: 90 days
621 on every plan.
622
623## More
624
625- [Quickstart](https://docs.g1t.sh/quickstart/)
626- [How g1t works](https://docs.g1t.sh/concepts/overview/)
627- [Search and Explore](https://docs.g1t.sh/guides/search/)
628- [g1t's agent](https://docs.g1t.sh/guides/working-with-g1t/)
629- [Outcomes and plans](https://docs.g1t.sh/guides/outcomes/)
630- [Talking to agents](https://docs.g1t.sh/guides/talking-to-agents/)
631- [Bring your own agent](https://docs.g1t.sh/guides/bring-your-own-agent/)
632- [The merge queue](https://docs.g1t.sh/guides/merge-queue/)
633- [Sessions and why-blame](https://docs.g1t.sh/guides/why-blame/)
634- [Forks and branches](https://docs.g1t.sh/concepts/forks/)
635- [Accounts and sign-in](https://docs.g1t.sh/guides/authentication/)
636- [Workspaces and tokens](https://docs.g1t.sh/guides/workspaces/)
637- [Access and roles](https://docs.g1t.sh/guides/access-and-roles/)
638- [Teams](https://docs.g1t.sh/guides/teams/)
639- [CODEOWNERS](https://docs.g1t.sh/guides/codeowners/)
640- [Managing a repository](https://docs.g1t.sh/guides/managing-repositories/)
641- [Integrations](https://docs.g1t.sh/guides/integrations/)
642- [Model providers](https://docs.g1t.sh/guides/models/)
643- [Webhooks](https://docs.g1t.sh/guides/webhooks/)
644- [GitHub Actions](https://docs.g1t.sh/guides/actions/)
645- [Self-hosted runners](https://docs.g1t.sh/guides/self-hosted-runners/)
646- [Usage and billing](https://docs.g1t.sh/guides/usage-and-billing/)
647- [Git](https://docs.g1t.sh/guides/git/)
648- [MCP tools](https://docs.g1t.sh/reference/mcp/)
649- [API reference](https://docs.g1t.sh/reference/api/)
650- [What g1t can't do yet](https://docs.g1t.sh/about/limitations/)
651- [An open letter to Cloudflare](https://docs.g1t.sh/about/open-letter-to-cloudflare/)
652- [Source](https://g1t.sh/flagon-io/g1t), MIT licensed
653
654## Help, status and policies
655
656- [Status](https://status.g1t.sh/): whether each part of g1t is working now, 90 days of uptime, and incidents; the same as JSON at https://status.g1t.sh/status.json
657- [Support](https://g1t.sh/support): where to get help (hey@flagon.io)
658- [Security](https://g1t.sh/security): how g1t protects code and accounts, and responsible disclosure (hey@flagon.io, https://g1t.sh/.well-known/security.txt)
659- [Policies](https://g1t.sh/policies): [Terms of Service](https://g1t.sh/policies/terms), [Privacy Policy](https://g1t.sh/policies/privacy), [Acceptable Use](https://g1t.sh/policies/acceptable-use), [Refunds and Cancellation](https://g1t.sh/policies/refunds), [Subprocessors](https://g1t.sh/policies/subprocessors)
660- g1t is made by Flagon, Inc. (https://www.flagon.io)