php项目依赖git协作，推荐简化git flow：main仅通过pr合并、develop用于集成测试、feature分支基于develop创建；.env和vendor/需忽略，composer.lock必须提交；统一psr-12规范并用php-cs-fixer自动格式化。
PHP 项目本身不提供版本控制，团队协作必须依赖 Git 这类外部工具——不是“PHP 怎么做版本控制”，而是“PHP 团队怎么用 Git 高效协作”。
Git 分支策略怎么选：main / develop / feature？
PHP 团队常用的是 Git Flow 简化版，而非严格遵循原始模型。关键不是名字，而是职责是否清晰：
-
main（或master）只允许通过 PR 合并，永远对应线上可部署状态 -
develop是集成分支，每日构建/测试目标，不应长期偏离main -
feature/xxx必须基于最新develop创建，完成功能后合入develop，不直连main - 避免使用
git push --force推送develop或main，尤其当多人共用时会丢提交
PHP 项目哪些文件不该进 Git？.env 和 vendor/ 怎么处理
PHP 项目中误提交敏感配置或第三方包是高频事故点：
-
.env必须加入.gitignore，部署时由运维单独注入；若需示例，提交.env.example并在 README 中说明字段含义 -
vendor/不进 Git（除非极特殊离线环境），靠composer install恢复；CI/CD 流程中应运行composer install --no-dev生产环境安装 -
composer.lock必须提交——它锁定依赖版本，否则composer install在不同机器上可能装出不一致的包 - 生成的缓存目录如
var/cache/（Symfony）、storage/framework/（Laravel）也应忽略
如何避免 PHP 协作中的编码冲突？psr-12 和 php-cs-fixer 实操建议
格式不统一不是风格问题，是合并冲突放大器。手动解决 <?php 前空格、括号换行差异极其低效：
Git版本控制与工作流 中文WORD版
下载
篇文章是针对git版本控制和工作流的总结，如果有些朋友之前还没使用过git，对git的基本概念和命令不是很熟悉，可以从以下基本教程入手： Git是分布式版本控制系统，与SVN类似的集中化版本控制系统相比，集中化版本控制系统虽然能够令多个团队成员一起协作开发，但有时如果中央服务器宕机的话，谁也无法在宕机期间提交更新和协同开发。甚至有时，中央服务器磁盘故障，恰巧又没有做备份或备份没及时，那就可能有丢失数据的风险。感兴趣的朋友可以过来看看
立即学习“PHP免费学习笔记（深入）”；
- 团队统一使用
php-cs-fixer+.php-cs-fixer.php配置，推荐基于psr-12扩展，禁用自动加declare(strict_types=1)（避免历史文件批量报错） - CI 流水线中增加
php-cs-fixer --dry-run --diff检查，失败则阻断合并 - 编辑器（VS Code）安装 PHP CS Fixer 插件，设置 “Format on Save”，但不要依赖它替代 CI 校验
- 禁止提交含
var_dump()、dd()、die()的调试代码——可用phpstan或自定义正则 pre-commit hook 拦截
本地开发和 CI 环境的 PHP 版本不一致怎么办？
本地跑通但 CI 报 ParseError: syntax error, unexpected token "string"（PHP 8.0+ 的命名参数语法）很常见：
- 在
composer.json的config.platform.php显式声明目标 PHP 版本，例如"platform": {"php": "8.1.0"}，让composer install模拟该环境解析依赖 - 用
php -v和composer show php双重确认当前实际版本与声明是否一致 - Docker 开发环境优先使用官方
php:8.1-apache镜像，而非宿主机 PHP；CI 脚本开头加php -v && composer --version日志输出，便于排查 - 避免在
if (PHP_VERSION_ID >= 80100)中混写新旧语法，PHP 8.0 下会直接 Parse Error，而不是运行时报错
真正的协作卡点往往不在 Git 命令本身，而在对 composer.lock 的信任程度、对 .env 生命周期的理解、以及是否把格式检查当成“可选项”。这些细节一旦松动，每天都会多出 15 分钟在 merge conflict 和 CI 失败上。
