Ps-Tech Git / GitHub workflow

Scope

• Encode PS-Tech defaults: linear history, rebase over merge for integrating work, draft PRs early, clean history before review, revert instead of rewriting shared history.
• Read GitHub state with gh when available (schemas first—see reference.md).
• Mutating git (rebase, push, revert): only when the user explicitly asks to run commands or recover from a described situation. Do not push, force-push, merge on GitHub, approve, or comment on PRs unless the user requests it.

Inspecting branches and PRs

1. Run from the repository root (or cd there first). If not a git repo, say so and stop there.
2. Prefer gh: gh auth status; then list/view PRs and checks (see reference.md).
3. Branches: git branch -a, git status; optional gh api repos/{owner}/{repo}/branches if JSON is needed (gh repo view --json nameWithOwner for owner/repo).

Linear history and branch roles

• production and staging: staging tracks production, often with a few extra commits. Updating production means moving it forward to staging (conceptually), using the flows below—not merge-button shortcuts that scatter merge commits.
• Dev branches sit on top of staging. If staging advances before the feature is ready, rebase the dev branch onto staging.