git lfs大文件仍被完整提交的主因是未提交.gitattributes文件；需先git add .gitattributes再commit，且已暂存的大文件须git rm --cached后重新add才能转为lfs对象。
Git 本身不适合存大文件，也管不住已提交的敏感数据——这两类问题必须用不同机制分别解决，混用只会让仓库更乱。
git lfs track 后为什么大文件还是被完整提交？
常见错误是只执行了 git lfs track "*.psd"，却没把生成的 .gitattributes 文件提交。Git LFS 的规则靠这个文件生效，不提交它，track 就等于没写。
- 执行
git lfs track后，务必运行git add .gitattributes再git commit - 已加入暂存区（staged）的大文件不会自动转为 LFS 对象，得先
git rm --cached <file></file>，再git add <file></file> - 如果文件已被推送到远程，仅改
.gitattributes不够，需用git lfs migrate import重写历史（慎用，会改变所有 commit hash）
.gitignore 加了 config.local.js 但 git status 还显示它？
因为该文件已经被 Git 追踪过。.gitignore 对已追踪文件完全无效——它只影响“未追踪”状态的文件。
Git Worktree
下载
Git Worktree 多需求并行开发助手：在当前 worktree 目录独立开发、修改、提交代码，不跨目录。基于目录命名规范自动识别仓库归属（如 main-repo-feature‑a → main‑repo 仓库）。遵循最小改动原则，从需求分析到 commit 交付全流程负责。触发场景：用户在 ...
- 确认状态：运行
git ls-files --cached config.local.js，有输出就说明已被追踪 - 解除追踪但保留本地文件：
git rm --cached config.local.js - 再提交：
git commit -m "stop tracking config.local.js" - 之后该文件才会真正被
.gitignore管住；若要彻底从历史中删除，需用git filter-repo或git filter-branch（注意：这会重写历史）
GitHub 上发现 .git 目录可访问，怎么快速确认是否泄露？
直接请求 /.git/HEAD 是最快验证方式。返回类似 ref: refs/heads/main 就说明暴露了，攻击者可进一步下载整个 .git 目录并用 git checkout 还原全部代码和历史。
- 别等工具扫描——手动 curl
curl -I https://example.com/.git/HEAD查看响应头和状态码 - 若返回 200，立刻检查 Web 服务器配置（Nginx/Apache）是否禁用了
.git路径的访问 - 临时补救：在 Web 根目录加
.htaccess（Apache）或location ~ /\.git规则（Nginx），但根本解法是修复部署流程，确保.git不随静态资源一起发布
真正麻烦的从来不是“怎么加规则”，而是规则生效的前提条件被忽略：LFS 依赖 .gitattributes 提交、.gitignore 无法覆盖已追踪文件、.git 暴露意味着整套历史可被一键还原——这些边界条件不厘清，再多配置也只是表面功夫。
