cherry-pick新提交的Author是原作者，Committer是当前操作者；需用--author="Name"或--no-commit后amend修正，否则易致权限校验失败或审计不通过。
别急着用 git reset --hard 或 git rebase，先确认你真正要解决的是什么问题——是本地误提交？是想把某个修复搬到另一个分支？还是需要清理提交历史？用错命令可能让同事的 pull 直接失败。
git cherry-pick 为什么挑完提交后 author 不对
默认情况下，cherry-pick 生成的新提交，Author 是原提交作者，Committer 是当前操作者。这在跨团队合入 hotfix 时容易触发权限校验失败或审计不通过。
- 临时修正：加
--no-commit参数暂存变更，再执行git commit --amend --author="Name <email>"</email> - 批量统一：直接加
--author="Name <email>"</email>（注意双引号包裹），例如git cherry-pick a1b2c3d --author="Alice <alice>"</alice> - 验证方式：运行
git log --pretty=fuller -n 1，检查Author和Commit字段是否符合预期 - 关键提醒：修改
author后，新提交哈希必然变化，不能认为“内容一样就是同一个提交”
git rebase 在公共分支上强推会出什么事
一旦你在 main 或 release/2.3 这类多人共享分支上执行 git rebase 并 git push -f，所有已基于旧历史工作的同事都会遇到 non-fast-forward 报错，强行 pull 可能丢失本地提交，甚至引发代码覆盖。
alfred-github-backup
下载
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
- 安全前提：只在自己独占的开发分支（如
feature/login-ui）上使用rebase - 同步主干推荐替代方案：用
git merge origin/main，保留可追溯的合并点 - 如果必须变基（比如整理本地提交），务必先
git checkout -b tmp-backup备份当前状态 - 远程分支被强推后，同事需手动重置：先
git fetch origin，再git reset --hard origin/main（仅限确认无本地未推送提交时）
git reset --soft、--mixed、--hard 的实际影响差异
三者本质都是移动 HEAD 指针，区别在于是否连带重置暂存区和工作区。最容易踩坑的是误用 --hard 导致未提交改动永久丢失。
-
--soft：只回退HEAD，代码修改和暂存状态都保留，适合改写提交信息或合并多次add -
--mixed（默认）：回退HEAD+ 重置暂存区，但工作区文件不变，适合重新选择哪些文件要提交 -
--hard：三者全清空，工作区未提交改动直接消失，永远不要对已有远程记录的提交用这个 - 查漏技巧：执行前先运行
git status和git diff，确认工作区是否有未保存的关键修改
最常被忽略的一点：无论 cherry-pick 还是 rebase，只要涉及提交重写，就一定改变 SHA-1 哈希值。这意味着 CI 流水线里基于旧哈希的缓存、PR 关联、甚至某些自动化部署脚本，都可能失效——不是功能出错，而是“找不到那个提交”了。
