git命令需理解工作区、暂存区、本地仓库三者边界；git add .易误塞无关文件，应优先用git add -u或git add -a并配合git status -s和git diff --staged核验；git commit --amend会彻底替换旧提交，仅限未推送时安全使用；git pull默认触发merge易冲突，推荐git pull --rebase或配置pull.rebase=true；git reset --hard后须立即用git reflog恢复，且所有撤销操作均无回收站。
Git 常用命令不是“背下来就能用”，而是得知道每个命令在什么状态下调、改了哪块区域、会不会丢数据。绝大多数误操作（比如 git reset --hard 后找不到提交）其实都源于没分清工作区、暂存区、本地仓库三者边界。
git add 什么时候该加点、什么时候不能加点
git add . 看似省事，但会把所有未被 .gitignore 拦住的改动全塞进暂存区——包括你不小心生成的 node_modules、dist/ 或临时日志文件。一旦 git commit，这些就进了历史记录。
- 只加当前目录下已跟踪且修改过的文件：
git add -u - 只加新增/修改的文件（跳过删除）：
git add -A - 想确认再加：先
git status -s看缩写标记，??是未跟踪，M是已修改，D是已删除，再针对性git add filename - 加完立刻
git diff --staged核对，避免误塞二进制或敏感文件
git commit -m 和 git commit --amend 的真实作用范围
git commit -m 只影响本地仓库，不触碰远程；而 git commit --amend 不是“编辑上一条提交”，它是用新提交**完全替换**旧提交——旧提交的哈希值作废，所有后续提交的父节点都会变。这在推送到远程后尤其危险。
Evez Github Manager
下载
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
- 仅限未推送的提交才安全使用
--amend - 如果已
git push，又用了--amend，必须git push --force-with-lease（不是--force），否则可能覆盖别人的新提交 - 想改提交信息但不改内容？
git commit --amend -m "new message"即可；想加文件进去？先git add再--amend
git pull 为什么经常引发冲突，以及怎么避开
git pull 实质是 git fetch + git merge 两步合并。只要本地有未推送的提交，又和远程分支有分叉，merge 就可能冲突——哪怕你只是改了一行注释。
- 日常开发建议用
git pull --rebase替代默认pull，它把你的本地提交“重放”到远程最新基础上，线性历史更干净 - 如果已配置
pull.rebase=true（推荐），那git pull就自动走 rebase 流程 - rebase 过程中遇到冲突，解决后不是
git commit，而是git add+git rebase --continue - 不确定时，先
git fetch查看远程变动，再手动git merge origin/main或git rebase origin/main
git reset --hard 的恢复窗口只有 reflog 存在时有效
git reset --hard 会同时丢弃暂存区和工作区的全部未提交变更，并把 HEAD 指向指定提交。它不删对象，但会让那些“悬空”的提交在 Git 垃圾回收（默认 30 天）后彻底消失。
- 误操作后第一反应不是慌，而是立刻执行
git reflog，找对应 HEAD@{n} 的哈希 - 恢复某次 checkout：
git reset --hard HEAD@{3}；恢复被 reset 掉的分支起点：git branch recover-branch HEAD@{1} -
reflog默认只记录 HEAD 变动，不记录其他引用；所以别依赖它救远端分支——那是git fsck --lost-found的范畴
真正容易被忽略的，是 Git 所有“撤销类”命令（reset、checkout --、clean）都没有回收站。它们生效即刻，且不校验你是否真想丢掉那些改动。养成执行前先 git status 和 git diff 的肌肉记忆，比事后翻 reflog 省力得多。
