rebase仅适用于未推送的本地分支，否则会重写提交哈希导致协作混乱；已推送分支需用--force-with-lease强制推送，冲突时用--continue或--abort处理。
rebase 会重写提交历史，别在已推送的分支上用
这是最常踩的坑：把本地 feature 分支 rebase 到 main 后直接 git push，结果被拒绝——因为远程已有相同分支名但提交历史不一致。Git 拒绝非快进（non-fast-forward）推送，本质是保护协作安全。
真正该用 rebase 的场景，只有一种：你自己的、尚未推送到远程的本地分支。比如刚从 main 拉出 feature/login，写了 3 个提交，此时 main 已有新提交，你想让自己的改动“叠”在最新 main 之上，再推送。
- 操作顺序：
git checkout feature/login→git rebase main→git push origin feature/login - 如果已推过，又想 rebase，必须加
--force-with-lease（不是--force），它会检查远程分支是否被别人更新，避免覆盖他人工作 -
rebase过程中遇到冲突，解决后用git add .标记，再执行git rebase --continue；不想继续就用git rebase --abort回退到 rebase 前状态
merge 和 rebase 的根本区别不在“要不要保留分支线”，而在“要不要改提交哈希”
很多人说 “rebase 让历史线性，merge 保留分叉”，这没错，但没说到根上。关键影响是：rebase 后每个提交的 SHA-1 哈希值都会变，而 merge 不会动原有提交。
这意味着：如果你在团队里用 rebase，别人基于你旧提交做的工作（比如 code review 评论、CI 构建记录、bug 跟踪链接），会全部失效——因为那些记录指向的哈希已经不存在了。
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
-
merge生成一个新提交（merge commit），引用两个父提交，历史可追溯，适合多人协作的长期分支 -
rebase把你的提交一个个“复制”成新提交，原提交被丢弃，适合整理本地小功能块，让 PR 更干净 - CI/CD 系统通常依赖提交哈希做缓存或标记，rebase 后缓存失效，可能重复构建；某些审计工具也靠哈希做完整性校验
交互式 rebase（rebase -i）是清理本地提交的唯一靠谱方式
写代码时随手 git commit -m "fix" 太常见，等要提 PR 时发现一堆琐碎提交。这时候别手动 reset + add + commit，用 git rebase -i HEAD~5 更安全可控。
它会打开编辑器列出最近 5 个提交，每行开头是命令词：pick（保留）、squash（合并到上一提交）、drop（丢弃）、edit（修改该提交）。
- 想把第 2、3、4 个提交合并进第 1 个？把它们前面的
pick改成squash，保存退出后会提示你编辑新提交信息 - 误操作导致 rebase 卡住？看终端提示的
git rebase --continue或--abort，别关终端 - 不要对
HEAD~n中包含已推送提交的范围做-i，否则等于主动制造哈希不一致
rebase 后 git log 看不到 merge commit，但 git reflog 里全都有
有人 rebase 完发现“原来那个提交不见了”，慌了。其实它没丢，只是从 git log 默认视图里隐去了——因为 log 只显示当前分支能到达的提交，而 rebase 后原提交已不可达。
这时用 git reflog 就能看到所有 HEAD 移动记录，包括 rebase 前的状态。你可以用 git reset --hard HEAD@{1} 回退到上一步（reflog 中的 HEAD@{1} 是 rebase 前的 HEAD）。
-
reflog是本地的、不共享的，只存在你机器上，所以它不能当备份用 - 想长期保留某次 rebase 前的状态？提前打个 tag：
git tag backup-before-rebase - 某些 GUI 工具（如 VS Code Git 插件）默认不显示 reflog，得手动调出或切命令行
