Git 常用场景速查：rebase、cherry-pick 和 reflog 救场

日常开发里真正会反复用到的 Git 操作就那么几个，整理成场景速查，比背命令有用。

拉取上游改动，保持提交线干净

git fetch origin
git rebase origin/main

rebase 会把本地提交“搬”到最新主干之后，历史是一条直线。注意：已经推到远端、别人在用的分支不要 rebase，会造成重复提交。

只把某个提交搬到当前分支

git cherry-pick 3f2a1c9

修 bug 时很常见：在 dev 上修好，只把这个修复拿到 release 分支，不带上别的改动。冲突时按提示解决后 git cherry-pick --continue。

提交信息写错了

git commit --amend -m "新的说明"

只改最后一次提交。已经推送的话需要 git push --force-with-lease，比 --force 安全，至少会在别人推过新提交时拒绝。

改到一半要切分支

git stash push -m "改了一半"
git stash list
git stash pop

pop 会应用并删除记录，apply 只应用、保留记录，冲突时更好收拾。

误删分支 / 误 reset

这是最救命的一条：

git reflog
# 找到那条 commit hash
git branch rescue <hash>

reflog 记录了 HEAD 的每一次移动，默认保留 90 天。只要提交过，基本都能捞回来。有人以为 reset --hard 就没了，其实对象还在，只是没有分支指向它。

看看这行代码是谁改的

git blame -L 40,60 app/store.py
git log -p --follow app/store.py

--follow 能跨重命名追踪历史，比 blame 更适合了解一段逻辑的演进。

最后一条经验：危险操作之前先 git status 确认工作区干净，或者干脆开个临时分支，成本几乎为零。