大多数php项目应选github flow而非git flow；composer包禁用dev-main依赖，须用语义化版本号；不建议为旧php版本维护兼容分支；需通过分支保护、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免费学习笔记（深入）”；
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。
