PHP团队协作需依托真实Git流程、统一规则与自动化卡点：main分支仅限PR合并且CI通过后自动打tag，develop为集成出口并强制测试，feature分支须带业务标识且生命周期≤5天；.env必须.gitignore、vendor不提交但composer.lock必须提交；全队共用PSR-12格式规范并CI校验；composer.json中config.platform.php需显式声明PHP版本，且CI运行时版本须与之严格一致。
composer.lock 不一致、.env 被提交、dd() 留在生产代码里的事故。
Git 分支怎么设才不翻车
别纠结「Git Flow 对不对」，盯住三个不可妥协的职责边界：
-
main分支必须永远可部署：只允许通过 Pull Request 合并，禁止直接 push；CI 验证通过后自动打 tag -
develop是每日集成出口：所有功能分支都基于它创建，合入前必须跑通单元测试 +php-cs-fixer --dry-run -
feature/xxx命名要带业务标识（如feature/api-v2-auth），生命周期不超过 5 天；超时未合入需 rebase 最新develop并同步说明阻塞点
常见错误：新人直接 git push origin main 覆盖线上部署状态；或长期挂着 feature/login 分支不合并，导致后续 PR 冲突文件高达 30+ 个。
哪些文件死都不能进 Git
PHP 项目最常因两处疏漏引发线上事故：
-
.env必须出现在.gitignore里——哪怕只有一行APP_KEY=xxx泄露，就等于交出应用控制权；用.env.example提交模板，字段加注释说明用途 -
vendor/绝对不提交（离线部署除外）：依赖由composer install恢复，但composer.lock必须提交——它锁死每个包的精确版本，否则不同机器composer install可能装出行为不一致的monolog/monolog2.10.0 vs 2.11.0
顺手检查命令：git status --ignored 看有没有漏忽略的缓存目录（如 storage/framework/cache、var/cache）。
立即学习“PHP免费学习笔记（深入）”；
PSR-12 不是审美选择，是合并效率刚需
当两个人改同一段代码，一个写 function foo($a, $b)，另一个写 function foo( $a , $b )，Git 就会把整行标为冲突——实际逻辑没变，但格式差异让合并变成体力活。
- 全团队共用一份
.php-cs-fixer.php配置，基础继承psr12，禁用declare_strict_types（避免老文件批量报错） - CI 流水线加检查：
php-cs-fixer --dry-run --diff --using-cache=no，失败则阻断 PR 合并 - VS Code 安装 PHP CS Fixer 插件并启用
Format on Save，但绝不信任它替代 CI——本地没开插件或配置失效时，CI 是最后一道防线
顺手清理历史：运行 php-cs-fixer fix src/ --rules=@PSR12 一次性格式化，但别立刻提交；先 git add -p 分块确认，避开误触的敏感逻辑块。
本地 PHP 版本和 CI 不一致？别靠猜
本地 PHP 8.2 写了命名参数 foo(name: 'x')，CI 用 PHP 8.0 报 ParseError: syntax error, unexpected token "string"——这种问题根本不用发生。
- 在
composer.json的config.platform.php显式声明目标版本，例如："platform": {"php": "8.1.0"} - 执行
composer show php确认 composer 解析的平台 PHP 版本，再比对php -v输出；两者不一致说明配置没生效或被其他 config 覆盖 - CI 脚本开头加校验：
[[ $(php -r "echo PHP_VERSION_ID;") -ge 80100 ]] || exit 1
真正容易被忽略的是：Docker 环境里 PHP 版本由镜像决定，config.platform.php 只影响依赖解析，不影响语法校验——所以 CI 的 PHP 运行时版本必须和声明严格对齐。
