git-rebase

Git 变基

执行所请求的变基，同时保留双方预期的行为和无关工作。仅仅请求变基，并不意味着授权压缩提交、丢弃提交、更改全局 Git 设置或发布重写后的分支。

1. 检查状态、当前分支、目标以及是否有正在进行的变基。复用已知目标和现有的 fetch 证据。保留未提交的工作；不要自动暂存、重置、切换分支、清理或暂存无关路径。必要时使用隔离的检出。
2. 开始新的变基之前，记录 HEAD；重写有价值的历史记录时，保留一个备份引用。bash <skill-dir>/scripts/pre-rebase-backup.sh 会为干净的分支创建备份，且不会修改已跟踪文件。已有经过验证的备份时，无需重复创建。
3. 默认直接变基到所请求的目标。仅当用户要求更改历史时，才执行交互式操作、压缩或重新排序；提交数量不是压缩的理由。只有在确实需要选择策略时，才查阅 references/strategies.md。
4. 发生冲突时，检查正在重放的提交、基底和双方的改动。变基期间，ours 是目标及已重放的提交；theirs 是正在重放的提交。追踪有变更的 API，并保留预期的安全性、状态和兼容性约定，而不是全盘接受任一方的改动。
5. 解决受影响文件中的冲突，检查其差异，只暂存已解决冲突的路径，然后继续变基。重复冲突时，复用有效的观察结果。不要在生产代码中添加合并历史注释，也不要在每个文件处理后运行完整测试套件。
6. 变基完成后，检查最终的补丁系列／差异，并运行针对受影响行为的检查以及项目要求的交付门槛。测试若发现回归，应修复生产代码，而不是弱化断言。
7. 仅在已获授权时发布。重写远程分支时，使用 --force-with-lease，并遵循项目当前的 head CI 策略。如果租约失败，检查远程新增的提交；不要改用无条件强制推送。

语义冲突请使用 references/resolution-patterns.md；已诊断的操作故障请使用 references/troubleshooting.md。辅助脚本位于该技能实际的 scripts/ 路径下；确认其仓库假设后，可选择使用 analyze-conflicts.sh／validate-merge.sh 作为辅助工具。它们不能替代项目所属的测试或门槛。丢弃工作的恢复操作仍需获得仓库的明确许可；备份引用是证据，不是重置许可。