github-pull-workflow

# GitHub 拉取工作流 ## 核心规则 每次拉取都是一次集成操作。先读变化、保护本地状态，再拉取与合并，并处理上游引入的逻辑或配置约定变化。 ## 工作流程 1. 确认仓库上下文。 - 执行 `git status --short --branch` 和 `git remote -v`。 - 确认当前分支、上游分支和目标远端。 - 没有上游或远端仍不明确时，拉取前询问用户。 2. 修改工作区前审查上游变化。 - 执行 `git fetch --all --prune`。 - 存在上游时，用 `git log --oneline --decorate --graph HEAD..@{upstream}` 查看历史。 - 优先阅读 `CHANGELOG.md`、`RELEASE.md`、README、迁移指南、发布说明、相关文档和提交正文。 - 更新较大、有明显风险或包含迁移时，在合并前说明影响。 3. 备份本地状态。 - 工作区无修改时，用 `git rev-parse HEAD` 记录恢复点。 - 有修改时，拉取前安全备份，优先采用临时备份分支或带明确说明的 stash。 - 不丢弃本地文件；用户未明确要求时，不执行会覆盖内容的 checkout、reset 或 clean。 - 备份判断包含未跟踪文件。 4. 拉取与合并。 - 按仓库既定约定选择 merge、rebase 或快进。 - 无明确约定时，使用正常拉取或可行的快进。 - 解决冲突时保留用户工作并理解上游意图。 - 合并后，对照拉取前恢复点检查最终差异。 5. 按需迁移逻辑与配置。 - 上游改变配置结构、目录、构建设置、生成代码规则、API、数据格式或功能约定时，同步更新依赖它们的本地文件。 - 本地定制须适配新规范，不能仅以合并后能编译为完成条件。 - 依据迁移指南和发布说明，不凭猜测迁移。 - 配置迁移保留本地值，同时转换键、嵌套、默认值和文件位置。 - 逻辑迁移同时处理依赖旧行为的调用点、适配、测试和文档。 6. 集成后验证。 - 运行最小且有意义的测试、构建、代码检查、格式或项目专项校验。 - 再执行 `git status --short`。 - 失败时区分上游、本地修改和迁移问题，再修复。 7. 汇报结果。 - 说明拉取范围及快进、合并提交或 rebase 方式。 - 说明版本变化、备份方法与恢复点、冲突及处理、已做与未完成迁移、验证命令和结果。 ## 安全要求 - 不静默覆盖用户修改。 - 汇报配置变化时不打印凭据。 - 生成文件变化时，先判断是否应由项目工具重新生成。 - 遇到破坏兼容性的上游变化且迁移决定不明时，完成备份和只读检查，再询问缺失决定。