Git workflow

Every NanoSite project is a git repository hosted by NanoSite. Your local folder is a normal clone of it. The AI builder in the web works on the same repository and makes its own commits. nanodev wraps the usual git steps so you rarely need to think about them, but plain git works too.

Pull and push

Get the latest changes:

nanodev pull

This fetches new commits and rebases: it puts your local commits on top of the latest code, as if you'd started from it. If package-lock.json changed, it also runs npm ci so your installed packages match.

Send your changes:

nanodev push

This commits your edits (or uses the commits you already made), pulls first if you're behind, and pushes. Push small changes often: it keeps everyone close to the same code and makes conflicts rare.

Prefer plain git? git pull --rebase and git push work the same way. nanodev's login sets up git credentials for you.

How AI builder changes arrive

The AI builder is just another git client:

At the start of each chat turn it updates to the latest code, including your pushes.
At the end of the turn it commits its changes and rebases them on top of anything pushed meanwhile.

So you're never blocked. You can push while the AI builder is working. Your push goes in, and the AI builder's commit lands after it.

When you push, the AI builder chat shows "Updated from local" with the number of files you changed, so the person chatting knows the code moved.

When the AI builder commits, nanodev dev tells you:

↓ 1 new commit on nano-site, run nanodev pull

nanodev status shows the same.

Conflicts

A conflict happens when you and someone else (a teammate or the AI builder) changed the same lines. Nothing is lost either way:

Your conflicts are resolved on your machine. You choose what to keep.
The AI builder handles its own. When its change overlaps yours, it merges its change with yours at the end of its turn. If it can't, it keeps its work and the AI builder chat offers Redo on the latest version.

When nanodev pull stops on a conflict:

Open the files git lists and choose the right version of each conflicting part.
Mark them resolved and continue:
```
git add <file>
git rebase --continue
```
Push: nanodev push.

To give up and go back to where you were before the pull, run git rebase --abort.

Restore and history

The project history in the web lists every commit: yours, your teammates' and the AI builder's.

Restoring an earlier point never rewrites history. It adds a new commit that puts the files back the way they were at that point. Before you confirm, the dialog lists the commits it undoes. To get the restore on your machine, run nanodev pull.

You can also undo locally with git (for example git revert) and push.

Private previews

nanodev preview

This builds your current local code, including uncommitted changes, in the same runtime your live store uses, and gives you a private URL. Use it to:

test checkout, which is disabled in local dev;
check that your pages render correctly in production before you share anything;
show work in progress to someone.

A preview doesn't change the shared code. Teammates and the AI builder don't see it until you push. You have one preview per project. Running nanodev preview again replaces it. A preview expires after 7 days without updates.

Publish

nanodev publish

This pushes your commits, then publishes that exact commit to your live site, and shows the build progress. If the AI builder commits something while your publish is building, it isn't included: you get exactly the code you pushed.

The Publish button in the web does the same with the latest shared code.

What the server rejects, and why

Every push is checked on the server. A rejected push changes nothing, and the message says what to fix.

Rejected	Why
Ignored paths: `node_modules`, `dist`, `.env` files and other build or local files	They're rebuilt in the cloud or hold secrets. The project's `.gitignore` lists them. The server applies its own list, so editing `.gitignore` doesn't change the rule.
Secrets: `.env*` files and well-known secret or token patterns (like private keys)	Your code is built and served by NanoSite. Secrets in the repository could leak.
Files over the size limit, or a push over the size limit	Keeps the repository fast to clone and build. Host large images and video on a CDN and use their URL.
`.git` paths, and file names that differ only by upper/lower case	They break on some systems or could change how git itself behaves.
`package.json` changes that add a package not on the allowed list	Only packages that are known to work in the NanoSite runtime can be installed. The message names the package.
A `package-lock.json` with packages from another registry, or without integrity hashes	The cloud installs from the public npm registry only, and checks every package against its hash.
A `package-lock.json` that can't install on Linux	The cloud builds on Linux. A lockfile made on Windows or macOS can miss Linux versions of some packages. `nanodev push` fixes this for you by adding only the Linux builds of packages you already have; versions never change. See Troubleshooting.
A website project without a subscription	Websites need a paid plan. Stores work on any plan.
A push that isn't based on the latest code	Someone pushed first. Run `nanodev pull`, then push again.

Packages

Your project's package.json and package-lock.json are the source of truth for its packages.

npm ci installs exactly what the cloud builds with. What runs on your machine is what runs live.
NanoSite never changes your dependencies automatically. No silent upgrades, in the cloud or locally.
Upgrade when you choose. Edit package.json or run npm install <package>@<version>, test with nanodev dev and nanodev preview, then push. The new lockfile is what the cloud installs from then on.
There's no nanodev add command. Use npm as usual. The push checks new packages against the allowed list.