最安全通用做法是先建新分支再git reset --hard回退原分支；原提交仍在reflog中30天内可找回，但强制推送前须确认远程保护策略并同步协作者。
直接说结论：用 git cherry-pick 或 git rebase --onto 能精准平移提交，但最安全、最通用的做法是先建新分支再 git reset --hard 回退原分支——前提是没推送到远程或已获团队同意强制覆盖。
git reset --hard 之后原提交还在吗
还在。Git 的 commit 对象不会被立即删除，只要没执行 git gc 或长时间未引用，它们就藏在 reflog 里，30 天内默认可找回。
-
git reflog能看到所有 HEAD 移动记录，比如HEAD@{2}: reset: moving to HEAD~3 - 想恢复？
git reset --hard HEAD@{2}就能回到 reset 前的状态 - 但注意：如果已
git push --force到远程，且别人已基于旧 HEAD 继续开发，强行回退会破坏协作
git cherry-pick 平移提交的坑
适合只挪几个提交、且不关心原始分支结构的场景；但它会生成**新 commit ID**，作者时间和提交时间不变，但 SHA-1 全变了。
- 重复 cherry-pick 同一提交会报错：
fatal: previous HEAD position was ... already applied - 如果有合并提交（merge commit），默认跳过；加
-m 1才能 pick 第一父提交 - 冲突时不能跳过，必须手动解决后
git add && git cherry-pick --continue - 批量操作建议用范围：
git cherry-pick A^..B（含 B 不含 A）
git rebase --onto 搬家整段历史
当你要把某段提交「从分支 X 上切下来，贴到分支 Y 后面」，git rebase --onto 是唯一干净解法。
- 语法：
git rebase --onto <new-base><old-base><branch-to-rebase></branch-to-rebase></old-base></new-base> - 例：把
feature分支上「从main分叉之后的所有提交」挪到dev分支末尾：git rebase --onto dev main feature - 执行后
feature指针会移动，原提交变成新 commit，但父子关系和变更内容完全保留 - 风险：如果
<old-base></old-base>指定不准（比如用了错误的 commit hash），可能漏掉或重复提交
推送到远程前必须确认的三件事
本地操作完只是开始，推送到远程才是协作链路的关键断点。
- 目标远程分支是否受保护？查
git ls-remote --heads origin看有无main/master，再确认平台设置里是否开启「push protection」 - 是否要强制推送？
git push --force-with-lease origin main比--force更安全，它拒绝覆盖别人新推的提交 - 其他协作者是否已拉取过旧提交？如果已有人基于你将要重置的 commit 继续开发，必须同步通知并协调 reset 时间
真正容易被忽略的不是命令怎么写，而是「谁依赖了这些提交」——Git 历史平移从来不是技术问题，是协作边界问题。一次 reset --hard 可能省五分钟，一次沟通缺失可能卡住整个团队两天。
