Source control and saved changes#

Review saved diffs, stage deliberate changes and keep local commits distinct from remote synchronization.

Before using Git#

Open a Git-backed project and save editor changes before reviewing Source Control. Confirm the repository root and current branch. Git works on saved files and the index; unsaved editor text can differ from the displayed diff.

Review, stage and commit#

  1. Refresh status and open the working-tree diff for each intended file.

  2. Stage only the changes you intend to include. Review the staged diff, including new files and deletions.

  3. Write a commit message describing the change and commit when the current host exposes that action.

  4. Read status and history again to confirm the resulting commit. A local commit remains local until an explicit remote transfer succeeds.

Cloud provider connections#

When Cloud exposes a GitHub or GitLab connection, complete its account authorization and select a repository you can access. Saving repository configuration does not fetch files or push commits. Inspect the selected project, provider, repository and branch before a separate fetch or push.

Project write permission and provider repository access are both required. A changed account, organization, workspace or provider connection can invalidate a pending operation. Keep provider credentials in the account connection flow, outside repository files and terminal arguments.

Conflicts and recovery#

If a save or Git operation returns an uncertain result, read status, diff and history before retrying. Repeating a commit or push blindly can create duplicate work. Preserve unrelated changes and recover on a separate branch or copy when appropriate.

The native Linux CLI uses alti ide workspace git with its own supported operations. WSL projects use the Linux workspace adapter. Neither path should be treated as an arbitrary Git shell. See CLI workspace operations and Local workspaces.