该报错本质是本地与远程分支历史分叉，无法快进合并；需主动选择git pull --rebase（保持线性历史）或git merge（保留并行上下文）整合，不可绕过。
git pull 报 fatal: Not possible to fast-forward 怎么办
这个报错不是 pull 失败，而是 Git 明确告诉你：本地和远程各自有对方没有的提交，历史已经分叉，它拒绝擅自做决定。你不能靠重试或换命令绕过去，必须主动选择整合策略。
常见触发场景：
- 同事刚推了新 commit，你本地还没拉取就执行了
git pull - 你在网页端（如 GitHub/GitLab）直接编辑并提交了文件，本地仍停留在旧 HEAD
- 你之前用过
git rebase改写过本地历史，导致和远程无法对齐
此时 git pull 默认尝试快进合并，失败后直接中止，不会自动创建 merge commit —— 这是 Git 的保守设计，不是 bug。
用 git pull --rebase 解决分叉但不引入 merge commit
这是多数协作场景下最安全、最干净的选择。它把你的本地提交“挪”到远程最新提交之后，保持历史线性，避免无意义的合并节点。
执行步骤：
- 先运行
git fetch origin确认远端状态（可选，但推荐） - 再运行
git pull --rebase origin main（把main换成你当前分支名） - 如果出现冲突，Git 会停在第一个冲突提交处，提示你解决
index.html、package.json等文件 - 手动编辑冲突文件，删掉
到>>>>> commit-hash的标记段，保留正确内容 - 执行
git add标记已解决，再git rebase --continue继续变基
注意：git pull --rebase 本质是 fetch + rebase，它不会改写远端历史，只调整你本地提交的父节点。但如果你已推送过这些 commit，后续再 push 就需要 --force-with-lease（见下节）。
什么时候该用 git merge 而不是 rebase
当你本地提交已公开（比如已推送到共享分支、被别人基于开发），或者你明确需要保留“并行开发”的上下文时，merge 更合适。它会生成一个真实的 merge commit，清晰记录两条线何时交汇。
OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：
操作方式：
- 确保工作区干净：
git status应无未提交更改 - 运行
git fetch origin拉取远端更新 - 执行
git merge origin/main（同样替换为你的分支名） - 若冲突，编辑文件 →
git add→git commit（提交信息可留默认）
性能与可读性权衡：merge 提交会让 git log --oneline 看起来略杂乱，但 git log --graph 能清晰还原协作脉络；rebase 让历史干净，但掩盖了真实开发时序，对审计或回溯不利。
push 仍被拒？检查 force 推送是否必要且安全
执行完 pull --rebase 后，如果 git push 依然报 [rejected] main -> main (non-fast-forward)，说明你本地的提交 SHA 已和远端不同——这是 rebase 的必然结果。此时必须用 --force-with-lease。
绝对不要用 git push -f（即 --force）：
-
--force会无视远端任何新提交，直接覆盖，可能删掉别人刚推的代码 -
--force-with-lease会校验远端分支自你上次 fetch 后是否被他人更新，若已被更新则中止，更安全
正确做法：
- 先
git fetch origin同步最新远端状态 - 再
git push --force-with-lease origin main - 如果提示 “stale info”，说明期间有人又推了新提交，你需要重新
pull --rebase再试
强推永远是最后手段。真正容易被忽略的是：很多团队在 CI/CD 流水线或分支保护规则里禁用了 force push，即使你本地成功，远端也会拦截——这时只能联系管理员临时放开，或换用 merge 方式同步。
