git add -u 只更新已跟踪文件的修改和删除，不添加未跟踪文件；它作用于整个工作区，默认不处理新文件，避免误提交，语义等价于 git add --update。
git add -u 只更新已追踪文件，不新增未跟踪文件
想把工作区里所有已被 Git 跟踪、且有修改或删除的文件立刻放进暂存区，git add -u 就是你要的命令。它不会碰任何新创建但还没 git add 过的文件（即 untracked 文件），这点和 git add . 有本质区别——后者会把新文件也一并暂存，容易误提交。
常见错误现象：执行 git status 后看到一堆 modified 和 deleted，但用 git add . 结果把不该进版本库的日志、临时配置全加进去了；这时候换 git add -u 就能干净收尾。
-
git add -u默认作用于当前目录及子目录（即工作区根路径） - 若只想更新某子目录下的已追踪变更，可加路径：
git add -u -- src/ - Git 2.0+ 默认启用
add.ignoreErrors，但若某文件被外部程序锁住，git add -u仍会报错中断，需手动排除或释放文件锁
git add --update 是 git add -u 的完整写法，语义更清晰
git add --update 和 git add -u 完全等价，只是长参数形式。在脚本或团队协作中，用 --update 更易读、不易误解——尤其当有人把 -u 误看成 “undo” 或 “unstage” 时。
使用场景：CI/CD 流水线中自动同步已追踪变更，或封装 Git 别名时建议用完整参数，避免歧义。
OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：
- 别名示例（写入
~/.gitconfig）：[alias]<br> up = add --update
- 执行
git up效果同git add -u，但意图明确 - 注意：别名不能覆盖内置命令名（如
add），否则会导致递归调用崩溃
git add -A 和 git add -u 的关键区别在哪
这是最容易混淆的一对命令。git add -A（或 git add --all）会同时处理三类文件：已追踪且修改、已追踪且删除、未追踪（new）文件；而 git add -u 只管前两类。
性能影响：在大型仓库中，git add -A 需遍历整个工作区查找 untracked 文件，I/O 开销明显高于 git add -u；尤其当项目含大量构建产物（如 node_modules/）又没写好 .gitignore 时，-A 可能卡顿甚至失败。
- 如果
.gitignore没配好，git add -u不受影响，git add -A可能把你不想提交的文件也扫进来 -
git add -u在 Git 2.0+ 中默认作用域是整个工作区（以前是当前目录），行为更统一 - 删除文件后仅用
git rm <file></file>是不够的——git add -u会自动把 staged deletion 补上
为什么 git add -u 有时像没反应？检查这三点
执行完 git add -u 再 git status 却还显示 modified？不是命令失效，大概率是这几个原因：
- 文件权限变更（如 chmod）在 Windows/macOS 默认不触发状态更新，
git config core.filemode false可关闭检测 - 行尾换行符（CRLF/LF）被 Git 自动转换，但工作区与暂存区内容实际一致，
git status仍标为 modified；用git diff --no-index /dev/null <file></file>可确认是否真有内容差异 - 文件被其他进程占用（如编辑器未释放锁、IDE 正在索引），Git 读取失败，但默认不报错——加
-v参数重试：git add -u -v，能看到具体哪个文件跳过了
真正难察觉的是换行符和文件权限这类“隐形变更”，它们不改变业务逻辑，却让 git add -u 看似失灵。遇到这种情况，先关掉 autocrlf 或 filemode，再试一次。
