github-pull-workflow

name	github-pull-workflow
description	通用 GitHub 拉取、版本日志阅读、备份、合并、冲突处理和迁移流程。Use when Codex needs to pull updates from GitHub in any project, inspect what changed first, protect local work, merge safely, and migrate logic or configuration structures to newer project conventions.

GitHub Pull Workflow

Core Rule

Treat every GitHub pull as an integration operation. Read what changed, protect local state, pull and merge carefully, then migrate local logic or configuration to any new conventions introduced upstream.

Workflow

1. Confirm repository context.

   • Run git status --short --branch and git remote -v.
   • Identify the current branch, upstream branch, and intended remote.
   • If the branch has no upstream or the remote is ambiguous, ask the user before pulling.

2. Review upstream changes before modifying the worktree.

   • Run git fetch --all --prune.
   • Inspect upstream history with git log --oneline --decorate --graph HEAD..@{upstream} when an upstream exists.
   • Read version logs first: check files such as CHANGELOG.md, RELEASE.md, README.md, migration guides, release notes, docs, and commit bodies.
   • Summarize what changed before merging when the update is large, risky, or includes migrations.

3. Back up local state.

   • If the worktree is clean, record the current commit hash with git rev-parse HEAD.
   • If there are local changes, create a safe backup before pulling. Prefer a temporary backup branch or stash with a descriptive message.
   • Do not discard local files. Do not run destructive checkout, reset, or clean commands unless the user explicitly asks.
   • Include untracked files in the backup decision.

4. Pull and merge.

   • Prefer the repo's established workflow: merge, rebase, or fast-forward according to project convention.
   • If no convention is obvious, use a normal pull or fast-forward where possible.
   • Resolve conflicts by preserving user work and integrating upstream intent.
   • After conflict resolution, inspect the final diff against the pre-pull backup point.

5. Migrate logic and configuration when needed.

   • If upstream changed configuration schema, directory layout, build settings, generated-code rules, API contracts, data formats, or feature conventions, update local files to the new structure.
   • Do not only make the merge compile; align local customizations with the new project norms.
   • Prefer migration guides and release notes over guesswork.
   • For config migrations, preserve local values while converting keys, nesting, defaults, and file locations to the new schema.
   • For logic migrations, update call sites, adapters, tests, and documentation that depend on the old behavior.

6. Validate after integration.

   • Run the smallest meaningful test, build, lint, format, or project-specific validation command.
   • Re-check git status --short.
   • If validation fails, diagnose whether the failure came from upstream, local changes, or migration work.

7. Report the result.

   • State the upstream range pulled and whether the merge was fast-forward, merge commit, or rebase.
   • Summarize version log findings.
   • List backup method and restore point.
   • Describe conflicts and resolutions.
   • Describe any migrations performed or still required.
   • Include validation command and result.

Safety Notes

• Never overwrite user changes silently.
• Never print secrets found in local config while summarizing changes.
• When generated files change, identify whether they should be regenerated by the project toolchain instead of manually edited.
• If upstream introduces breaking changes and the correct migration is unclear, stop after backup and pull inspection, then ask for the missing decision.