Git and changes

Saving a page changes a working file. A Git commit records a reviewed set of changes. Pushing publishes recorded commits to a remote.

Inspect before recording

Open Project → Repository changes and history, or the repository entry in the sidebar. Changes shows staged and unstaged diffs. History opens recorded commits and their patches.

Diffs are read-only snapshots; use Refresh when another tool has changed the repository. Open a working file in its document tab to edit it. Large previews may be truncated and are labeled accordingly.

The bottom Git status describes the last local observation. An ahead/behind count based on local remote references is not a fresh fetch from the server.

Stage and commit

1. Review the changed files.
2. Select the paths to Stage; open buffers for those paths are saved first.
3. Inspect the staged changes and write a commit message.
4. Use Commit staged for the reviewed set.

Unstage a path if it does not belong in this commit. A commit message can remain a draft while you inspect the changes. Autosave never invokes these Git actions for you.

Fetch, update and publish

• Fetch updates knowledge of the remote.
• Update uses a fast-forward when it can preserve local work. It does not silently stash or merge around a conflict.
• Push sends the reviewed commit to the configured upstream.
• Publish lets a branch without an upstream choose an existing remote and destination branch explicitly.

If another tool changes the repository during an operation, read the reported outcome and refresh before retrying. A confirmed push and a failed follow-up refresh are different states.

The current repository view does not provide hunk acceptance or a general revert command. Use your Git tools for operations it does not expose, preserving local edits as usual.