Safe GitHub pull request workflow for low-experience Git users. Use when pulling, syncing a feature branch with `main`, resolving conflicts, undoing mistakes, recovering from a bad rebase, or deciding how to merge a PR while keeping `main` clean. Triggers on: "update my branch", "rebase my branch", "resolve git conflicts", "recover from rebase", "undo pushed commit", "keep main clean", "squash merge".
42:T1a80,
Guide users through a GitHub-first PR workflow that keeps main clean without requiring
frequent local rebases. Prefer short-lived feature branches, merge origin/main into the
feature branch when syncing, and land changes with Squash and merge.
Bias toward safety over elegance. Choose reversible operations, avoid rewriting shared history, and teach the user in small steps while you work.
main and master as shared, sensitive branches.git fetch before any sync, merge, or recovery action.origin/main into a feature branch over rebasing it.git revert over rewriting history when commits may already be pushed.Squash and merge to keep main clean.Before any Git operation that changes history, branches, or remote state, inspect:
If you cannot determine whether a branch is shared, assume it is shared and choose the safer path.
Use this as the default GitHub workflow for low-experience users:
main.main, merge origin/main into the feature branch.Squash and merge.Do not teach users to routinely rebase pushed PR branches just to get the latest main.
That workflow is where many novices re-introduce old code or lose work.
When helping a user open a PR, treat the PR title as the likely final squash-merge commit.
main after Squash and merge.WIP, fix stuff, address comments, or update branch.Good default patterns:
feat: add <skill-name> skillfeat(<skill-name>): add <capability>fix(<skill-name>): correct <problem>docs: document <policy or workflow>For the PR body:
If the repo uses GitHub squash merges, prefer the PR title as the default squash commit message.
main on a feature branch? Use fetch, then merge origin/main into the
feature branch.main history? Rely on Squash and merge, not local rebasing of the feature
branch.revert.If a user asks to rebase a pushed branch, explain why that is risky and propose merging
origin/main instead.
For detailed conflict-handling steps and examples, read references/conflict-resolution.md.
reflog or rebase abort.revert.For recovery playbooks, read references/recovery.md.
main unless the user explicitly asks and the repo policy allows it.main or other protected branches.git reset --hard, git clean -fd, branch deletion, or tag deletion unless the user
clearly wants destructive cleanup.If the user explicitly wants a risky operation, explain the safer alternative first. Only proceed when the request is clear and the branch is not a protected/shared branch.
Teach in short, repeatable notes while working:
origin/main, explain that this preserves the branch's existing commits and is
easier to recover from.When asked how to support this workflow at the repo level, recommend:
mainSquash and mergeRebase and mergePull request titleFor repo policy details, read references/repo-settings.md.
Before syncing a feature branch:
mainorigin/main, do not rebase by defaultBefore pushing:
status and diffBefore undoing:
revert for pushed work