PHP版本选择攻略与推荐

本文深入剖析了PHP项目在版本分支管理中的关键实践：主张多数PHP项目采用简洁高效的GitHub Flow而非复杂的Git Flow，严禁在生产依赖中使用不稳定的dev-main，坚持语义化版本发布以保障构建可复现与协作一致性，明确反对为旧PHP版本维护独立兼容分支——而应通过代码规范和静态分析统一管控语法水位，最后强调必须借助分支保护规则、Composer platform配置和CI环境校验等自动化手段将策略真正落地，让每一次合并、部署和故障回溯都成为流程健壮性的验证。

PHP 项目该用 Git Flow 还是 GitHub Flow？

大多数 PHP 项目不需要 Git Flow。它引入的 develop、release/*、hotfix/* 分支，反而让 Composer 包发布、CI 构建和环境部署变复杂——尤其是当你的项目用 composer install --no-dev 部署时，develop 分支根本不能直接上线。

GitHub Flow（即：主干为 main，功能开 feature/xxx，PR 合并前必须通过测试+人工评审）更适合 PHP Web 应用和 Laravel/Symfony 项目：

• main 始终可部署，配合 GitHub Actions 或 GitLab CI，每次 push 到 main 自动跑测试 + 部署到预发
• 避免 hotfix 分支和线上 tag 错位问题——PHP 没有强版本锁机制，靠分支打 patch 容易漏同步
• Laravel 的 php artisan migrate 必须按顺序执行，多分支并行改 migration 会导致线上迁移失败，而 GitHub Flow 强制串行合并，天然规避这点

Composer 包该不该用 dev-main 当依赖？

不该。在 composer.json 里写 "my/package": "dev-main" 看似方便，实则破坏语义化版本约束，导致以下问题：

• CI 构建结果不可复现：今天 dev-main 是 commit A，明天合入一个 PR 就变成 B，缓存失效、测试行为突变
• 团队协作混乱：有人本地 composer update 拉到新代码，有人没拉，git status 看不出差异
• 无法精准回滚：出问题时你不知道具体是哪个 commit 引起的，因为 dev-main 不对应任何固定版本号

正确做法是：包作者发版后打 v1.2.0 tag，使用者明确锁定 "my/package": "^1.2.0"；开发调试阶段可用 path repo 临时链接本地源码，但上线前必须切回正式版本。

PHP 8.1+ 项目要不要为旧版本维护兼容分支？

不建议单独开 php74 或 php80 分支。PHP 本身不提供跨大版本的运行时兼容层，硬撑只会让代码越来越丑：

• 类型声明、match 表达式、枚举等特性无法降级，最后只能靠 @phpstan-ignore-line 或条件编译注释糊弄
• 第三方库（如 Doctrine、Nette）早已停止对 PHP 7.4 的安全更新，分支再维护也挡不住底层漏洞
• CI 配置爆炸：每个分支要配不同 PHP 版本的容器、不同最低要求的扩展版本，维护成本远超收益

如果客户强要求 PHP 7.4 支持，优先评估是否能推动其升级；实在不行，就在 main 分支用 phpstan + php-cs-fixer 控制语法水位，而不是分裂分支。

如何让分支策略真正落地不流于形式？

靠流程工具卡住比靠文档管用。重点配置三处：

• GitHub/GitLab 的 branch protection rule：强制 main 只允许 PR 合并，且必须通过 phpstan、psalm、单元测试三个检查
• Composer 的 config.platform.php 显式声明项目所需最低 PHP 版本，防止本地 composer install 拉错依赖
• CI 脚本里加一行：php -v | grep -q "8\.1" || exit 1，确保构建环境 PHP 版本不被意外降级

最常被忽略的是：分支策略不是写完就完事，而是每次 merge 冲突、每次 deploy 失败、每次线上报错，都要反查是不是分支管理松动导致的。比如 main 上突然出现未测代码，大概率是跳过了保护规则或用了 force push。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~