Git and GitHub

The chip at the right of the title bar shows the current branch and whether the tree is dirty. Its dropdown is where version control happens.

Committing and pushing

Write a message and commit; push sends it to the remote. The chip shows the repository name and links to it on GitHub when there is a remote.

Switching branches with work in progress

Git will not switch over changes it would have to overwrite, and the usual advice (commit them first) means a commit made to satisfy git, on work that is not finished.

Stacki sets that work aside against the branch it was written on, and takes it back out when that branch is next opened. Nothing is committed, and nothing travels to a branch it does not belong to. The switcher marks any branch holding work this way, so where you left it is visible rather than something to remember.

Details worth knowing:

• Only an entry Stacki wrote is ever restored, so a stash you made by hand is left alone.
• Creating a branch carries the work onto it, which is what starting a branch from what is in front of you means.
• A switch that fails puts the work straight back rather than leaving it stashed behind a change that never happened.
• Work that no longer applies, because the branch moved under it, stays parked and says so, and the tree is returned to the branch as committed. A stash that cannot apply would leave conflict markers in files that are parsed a moment later, which is a fair state at a terminal and a bad one here.

Publishing to GitHub

Publish to GitHub creates a repository and pushes to it, using the GitHub CLI. Authenticate once with gh auth login and Stacki uses that session; it never asks for a token of its own.

Deploying

Stacki does not deploy. The project is an ordinary Astro project in an ordinary git repository, so whatever you already use (Netlify, Vercel, Cloudflare, a GitHub Action) works unchanged.