PHP版本控制团队协作指南

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 实操建议

格式不统一不是风格问题，是合并冲突放大器。手动解决 前空格、括号换行差异极其低效：