git reset --hard 可回滚本地分支到指定 commit，但会永久删除其后所有提交及未暂存更改；远程需配合 git push --force-with-lease 强制更新，且须确保无协作者依赖被丢弃的提交。

git reset --hard 回滚本地分支到指定 commit

远程仓库不能直接回滚，必须先在本地把分支退回到目标版本，再强制推送到远程。最常用的是 git reset --hard，它会重置当前分支的 HEAD、暂存区和工作目录，三者完全对齐到指定 commit。

操作前务必确认：该分支近期没有其他人基于你将要丢弃的提交继续开发，否则强制推送会造成协作混乱。

• 查目标 commit ID：git log --oneline -n 20 或用 git reflog 找到你想要回退到的 HEAD@{n}
• 执行硬重置：git reset --hard <commit-id></commit-id>（例如 git reset --hard a1b2c3d）
• 验证是否成功：git log 看最新提交是否已变为目标 commit
• 注意：所有未提交的修改、未 push 的提交都会被永久删除，无法通过 git pull 恢复

git push --force-with-lease 覆盖远程分支

本地回滚后，git push 默认会拒绝推送，因为远程分支的 commit 历史比本地“新”。必须用强制推送，但推荐用 --force-with-lease 而不是 --force —— 它会检查远程分支自你上次 fetch 后是否被他人更新，避免误覆盖别人的新提交。

Github Stars Analyzer

抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...

下载

• 确保已 fetch 最新状态：git fetch origin
• 强制推送：git push --force-with-lease origin main（把 main 换成你的分支名）
• 如果提示 “failed to push some refs”，说明远程已有新提交，此时应先沟通确认，不要强行加 --force
• CI/CD 系统或受保护分支（如 GitHub 的 main）可能禁止 force push，需临时取消保护或走 PR 流程

用 git revert 替代 reset 的安全回滚方式

如果你只是想撤销某次提交引入的变更，又不想破坏提交历史（比如多人共用分支、需要审计追踪），就别用 reset，改用 git revert。它不删除历史，而是新增一个“反向提交”来抵消原效果。

• 撤销单个提交：git revert <commit-id></commit-id>（例如 git revert a1b2c3d）
• 撤销连续多个提交：git revert <oldest-commit>^..<newest-commit></newest-commit></oldest-commit>（注意 ^ 表示排除起点）
• revert 后正常 git push 即可，无需 force；但要注意冲突：如果被 revert 的代码后续又被修改过，revert 过程中会报 conflict，需手动解决
• revert 生成的新提交仍保留在历史里，适合生产环境或合规要求高的场景

回滚后如何恢复被 reset 掉的提交

万一你用 git reset --hard 之后发现删错了，只要还没做新的 commit 或 gc，通常还能找回。Git 会把旧引用暂时保留在 reflog 里，最多保留 90 天（默认配置）。

• 查看操作日志：git reflog，找到 reset 前的 HEAD 位置（如 HEAD@{1}）
• 恢复分支指向：git reset --hard HEAD@{1}
• 如果 reflog 已清空或太旧，且没 push 过，只能靠 IDE 的本地历史（如 VS Code 的 File → Revert to Saved）或文件系统快照尝试抢救
• 真正保险的做法是：回滚前先建临时分支备份，git branch backup-before-reset

强制推送是把双刃剑，尤其在共享分支上——看似一步到位，实则把协作信任变成一次性操作。真正的难点不在命令怎么敲，而在判断“谁依赖这段历史”以及“有没有更轻量的替代方案”。