git add 只添加某个目录下的文件，核心是用相对路径精准指定目录（如 git add src/），Git 会递归添加该目录下所有未忽略的已跟踪和未跟踪文件；若无效，需检查 .gitignore 或用 -f 强制添加。
git add 只添加某个目录下的文件
想提交特定目录，核心是让 git add 精准识别路径范围，而不是把整个工作区都加进去。Git 默认不会递归忽略子目录里的新文件，所以只要路径写对，它就会把该目录下所有「已跟踪」和「未跟踪但非忽略」的文件一并加入暂存区。
常见错误是直接写 git add mydir/ 却发现没反应——其实不是没用，而是该目录下没有符合添加条件的文件（比如全被 .gitignore 拦住了，或者全是已提交过的未修改文件）。
- 用相对路径，从当前工作目录出发，如
git add src/utils/ - 确保末尾不带
*（git add src/utils/*会由 shell 展开，可能漏掉以点开头的文件，且无法处理空格路径） - 如果目录里有新文件被
.gitignore覆盖，先用git check-ignore -v src/utils/newfile.js确认是否真的被忽略 - 想强制添加被忽略的文件？加
-f：git add -f src/utils/debug.log
提交时只包含指定目录的变更
git commit 本身不接受路径参数，它只提交当前暂存区里的内容。所以“提交指定目录”本质是两步：先用 git add 把目标目录相关变更放进暂存区，再 git commit。不存在一步到位的 “git commit -C src/” 这种写法。
容易踩的坑是：在执行 git add src/ 前，已经手动 git add . 或其他目录，导致暂存区混入了不想要的变更。这时可以用 git reset 清理：
- 撤回某个目录的暂存：
git reset HEAD src/config/ - 确认暂存区只含目标内容：
git status --short src/ - 提交时建议加
-m明确说明范围，例如：git commit -m "chore: update src/api client"
避免误提其他目录的修改
当工作区存在多个目录的未提交变更时，仅靠 git add dir/ 并不能自动排除其他目录的修改——Git 不会帮你“反向过滤”。如果你刚改了 docs/ 和 src/，只 add src/，那 docs/ 的改动就留在工作区，下次 git add . 或疏忽中仍可能被一起提交。
本地项目发布到GitHub的完整工作流助手。自动执行：安全检查（.gitignore、排除敏感.env/凭据文件）、补齐开源文件（LICENSE、.gitignore）、git init/commit/branch、创建远程仓库、首次推送、可选打tag。支持git filter-repo历史敏感信息重写、force push、tag管理。Windows下走Credential Manager自动认证。触发词："发布到GitHub"、"上传到github"、"
- 提交前必看：
git status，重点扫一眼 “Changes not staged for commit” 区域 - 用
git diff --staged src/确认暂存区里确实是你要提交的内容 - 如果经常需要隔离提交，考虑用
git add -p交互式选择 hunks，比目录粒度更细、更安全 - CI 或团队规范里常要求单次提交聚焦一个逻辑单元，此时按目录提交只是手段，关键还是得人工核对变更范围
git push 不涉及目录控制
git push 推送的是本地分支的全部提交记录，和“哪个目录被改过”完全无关。你无法用任何参数限制它只推送某几个目录的提交。也就是说：只要提交对象（commit hash）进了分支历史，它包含的所有文件变更都会被推送到远程。
这点特别容易误解——有人以为 git push origin main --include src/ 这类命令存在，但实际上 Git 没有这种机制。若真要分目录发布，得靠分支策略（如为 ui/ 和 api/ 分设不同分支）或后续用 git archive / 构建脚本提取子集，而非 push 时控制。
真正容易被忽略的是：重写历史（如 git rebase -i）后，如果之前提交混入了不该出现的目录变更，即使现在只 add 了干净目录，那些旧提交依然带着脏内容——清理必须从源头做。
