Composer拉不到刚push的代码，根本原因是其不实时跟踪Git分支HEAD，而是依赖缓存的元数据、composer.lock锁定的commit hash及版本约束；强制更新需组合执行composer update --no-cache --with-dependencies vendor/package，或删composer.lock后composer install以重新解析dev分支最新提交。
Composer 拉不到刚 push 的代码，基本不是 Git 本身的问题，而是 Composer 默认不跟踪分支最新提交——它只认 composer.json 里声明的版本约束（如 "dev-main" 或 "^1.2"），且依赖本地缓存的元数据和已锁定的 dist 地址。真要拉新 commit，得主动打破缓存链。
为什么 composer update vendor/package 还是旧代码？
Composer 不直接 clone 分支，而是通过 Packagist 或你配置的 VCS 源解析出一个“可安装版本”，再从 dist（zip 包）或 source（git clone）安装。即使你刚 push 到 main 分支，只要没触发版本号变更（比如没打 tag、没改 composer.json 的 version 字段），Composer 就不会认为有“新版本”可更新。
-
dev-main这类开发分支别名，实际对应的是 Packagist 缓存的最后一次扫描结果，不是实时 git head - 如果你用的是私有 Git 仓库，Composer 默认只在首次安装或
composer update --lock时重新 fetch refs，之后就复用缓存的 commit hash -
composer.lock里记录的是具体 commit id（"reference": "abc123..."），不改 lock 文件，就不会换 commit
强制拉取最新 dev-* 分支的实操步骤
想跳过所有缓存、直取远程分支 HEAD，必须组合三步：清元数据缓存 + 强制重解析 + 绕过 lock 约束。
- 先确认目标分支确实可被识别：运行
composer show vendor/package -v，看输出里source的reference是否仍是旧 commit；如果显示dev-main但 reference 没变，说明没刷新 - 执行
composer update --no-cache --with-dependencies vendor/package：--no-cache跳过本地元数据缓存，--with-dependencies防止因子依赖锁死导致跳过 - 若仍不行，删掉
composer.lock中该包的条目（或整个文件），再跑composer install—— 这会强制从composer.json重新解析，抓最新dev-main的 commit - 注意：如果包未在 Packagist 注册，且项目中用了
"repositories"指向 Git URL，确保该 URL 可公开访问，且 Composer 能读到composer.json（不能放在子目录下）
Git 仓库配置里最容易被忽略的坑
很多私有包拉不到新 commit，问题不在 Composer，而在 Git 源配置本身没生效。
- 在
composer.json的"repositories"里写"type": "vcs"时，URL 必须是完整 Git 地址（如"https://github.com/vendor/repo.git"），结尾.git缺不得 - 如果 Git 仓库启用了 GitHub/GitLab 的 branch protection，而你的新 commit 在 protected 分支上且未通过 CI，Packagist 可能拒绝扫描该分支（表现为
dev-main停滞） - Composer 默认只扫描默认分支（通常是
main或master）。若你 push 到dev-feature，需显式声明："require": {"vendor/package": "dev-dev-feature as dev-main"} - 某些 Git 托管平台（如 Gitee）对未公开仓库返回 404，但 Composer 不报错，只是静默 fallback 到其他源 —— 用
composer update -vvv看日志里是否出现Cloning into或Failed to download
真正卡住的往往不是命令没敲对，而是你以为 Composer 在“拉分支”，其实它在“装版本”；你以为删了 vendor 就重来，其实它还在按 lock 文件还原。关键动作永远落在元数据刷新、lock 文件控制、和 VCS 源可达性这三点上。
