git分支直接决定composer dev-*版本的可require性，仅按字面匹配分支名（如dev-main、dev-feature/login），不解析语义；main分支对应dev-main，feature分支须写全路径且require严格一致，否则报“could not find matching version”。
Git分支怎么管Composer扩展包的版本节奏
扩展包不是主项目，它的 Git 分支直接决定 dev-* 版本能否被 require 到。main（或 master）分支对应 dev-main，feature 分支就得写成 dev-feature/login——Composer 不解析分支语义，只按字面匹配。如果本地开发用的是 dev-new-api，但主项目 require 写的是 dev-main，哪怕两个分支代码一模一样，也会报 Could not find a matching version。
常见做法是：
• 主干用 main 分支承载稳定 API，对外提供 dev-main
• 新功能走 feature/xxx，PR 合并前让使用者临时 require dev-feature/xxx
• 发正式版时打 tag（如 v1.2.0），之后主项目就能切到 "vendor/name": "^1.2"，不再依赖 dev 分支
为什么 composer.lock 不能进 .gitignore
composer.lock 必须提交，否则团队里每个人 composer install 装出来的包实际 commit hash 可能不同——尤其是你用 dev-main 时，它锁的就是当前 HEAD 的哈希值。不提交 lock 文件，等于放弃可复现性。
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
容易被忽略的点：
• composer.lock 变更后，必须和 composer.json 一起 git add 并 commit
• 如果合并 PR 时出现 lock 冲突，不要手动编辑，执行 composer update --lock 重生成（不升级依赖，只对齐结构）
• CI 环境若提示 Lock file is not up to date with composer.json，说明有人只改了 json 没跑 install/update，得回退或补操作
私有扩展包协作时 Git 权限和 Composer 配置怎么对齐
用 SSH 地址配 repositories 是最稳的方式：{"type": "vcs", "url": "git@github.com:org/pkg.git"}。HTTPS 方式必须提前配 token：composer config --global github-oauth.github.com your_token，否则 composer install 在 CI 或新同事机器上会卡住或 401。
关键细节：
• require 中的包名必须和该仓库内 composer.json 的 name 字段**完全一致**（大小写、vendor 名、斜杠位置）
• 私有包自己的 composer.json 至少要有 name 和 autoload，否则 Composer 识别为无效包，连扫描都跳过
• 如果用 GitHub Actions，记得在 secrets 里设 SSH_PRIVATE_KEY 并在 job 中用 webfactory/ssh-agent 注入，否则 clone 失败
本地开发时 Git commit 和 Composer symlink 怎么协同
path 仓库模式下，Composer 默认复制文件，改本地代码不会同步到 vendor/。要热更新，必须启用 symlink，而 symlink 依赖 Git 状态：Composer 只认已 git init 且至少有一个 commit 的目录。
实操要点：
• 本地包初始化后立刻 git init && git add . && git commit -m "init"，否则 composer require 直接跳过该路径
• 在主项目 repositories 条目中加 "options": {"symlink": true}
• 改完本地包代码后，运行 composer update vendor/name（不是 install），才会刷新 symlink
• Windows 用户需开启“开发者模式”或以管理员身份运行命令行，否则 symlink 创建静默失败
