# Git (https://lazyfrog.dev/docs/guide/git)

{/* Generated by scripts/generate-docs.ts from services/gateway/src/guide.md. Do not edit. */}

`/workspace` is a git repository (`/data` and the database are not in it). Commit with the `git`
tool or `git` in `exec`: commits are authored as the user, and the `git` tool adds you as
co-author. A commit containing what looks like a secret (an API key, a token) is refused with the
file and line: put the value in `secrets` and read it from the environment.

Commits carry the user's name and email (Account › Commit author in the portal; the default is
their account name and email). A commit's author is public as soon as the repository is: before you
set a remote that is public (GitHub, GitLab, any public repository), tell the user which name and
email their commits show and that they can change them in their account.

To send the code to GitHub: if the portal offers a GitHub connection and the user made it (Project › Code), `git`
`remote_set` with `github: "owner/name"` and push; there is nothing to add on GitHub. For any
other host (or GitHub without the connection), `remote_set` with the repository's SSH address
(`git@gitlab.com:user/app.git`) returns a deploy key: ask the user to add it to the repository
with **write access**, then `push`. `pull` brings changes back (a snapshot is taken first). Every
project starts with a `Dockerfile` and `compose.yml`, so a clone runs anywhere with `docker compose up`.
Keep them working when you change the stack (preflight and publish warn without a Dockerfile).

The user can also `git clone https://git.lazyfrog.dev/<project>.git` with a personal token from
the portal (Account › Access tokens) as the password, and push to it to update the preview with a
token made "Read and write". You cannot make tokens. Every project's repository has that address
as its remote: `origin` when it has no other, else `lazyfrog` (a GitHub `origin` stays `origin`).

A push to git.lazyfrog.dev, or with the GitHub connection to the repository's branch, updates the
preview by itself: the preview's uncommitted work is committed first (a push to git.lazyfrog.dev
does that, as "Changes made in the LazyFrog workspace"), a snapshot is taken, the branch
fast-forwards, the dependencies are installed again when the push changed them, pending
`migrations/` run on the preview's database, the services restart and are health-checked; with
`project` `settings` `auto_publish: true` (on a paid plan) a working preview is then published.
Pull before you edit when the user says they pushed from elsewhere. When you work in a checkout
yourself (Claude Code, Codex), see "Working from a checkout".