PHP 怎么PHP项目合作

本文目录导读：

1. 基础工具链（必备）
2. 代码规范与质量（核心）
3. 架构与协作模式
4. 工作流（Pull Request + Code Review）
5. 测试（CI/CD）
6. PHP 项目特有的合作“坑”与对策
7. 推荐 PHP 项目团队工作流（实操案例）

在 PHP 项目中进行多人合作，核心在于规范化、自动化和清晰的沟通，以下是 PHP 项目合作的完整指南，从工具链到代码规范，再到工作流程：

---

基础工具链（必备）

这是合作的基石,缺少任何一个都会导致混乱。

版本控制（Git）

• 必须使用：Git 是唯一的选择（GitHub / GitLab / Gitea）。
• 分支模型：推荐使用 Git Flow 或 GitHub Flow。
  • main/master （生产分支）：永远可部署。
  • develop （开发分支）：集成功能。
  • feature/* （功能分支）：每个新功能一个分支，从 develop 拉出。
  • hotfix/* （热修分支）：修复生产环境紧急 bug。
• 提交规范：使用 Conventional Commits（常规提交）。
  • feat: 添加用户注册功能
  • fix: 修复登录时验证码不显示的问题
  • refactor: 重构订单查询逻辑
  • docs: 更新API文档

依赖管理（Composer）

• 必须使用 Composer 管理第三方库（Laravel、Symfony 等）。
• 重要规则：
  • composer.lock 文件必须提交到 Git 仓库（保证生产环境和团队版本一致）。
  • vendor/ 目录必须忽略（.gitignore），不要提交。
• 新成员拉取代码后只需运行 composer install。

环境一致性（Docker/Valet/Herd）

• 避免“在我电脑上是好的”这种问题。
• 推荐使用 Docker（建议使用 Laravel Sail 或者 Docker Compose）来统一开发环境（PHP 版本、扩展、MySQL、Redis）。
• 如果不使用 Docker，必须约定统一的 PHP 版本（如 PHP 8.3）和扩展列表，并确保团队成员一致。

---

代码规范与质量（核心）

PHP 语言比较灵活，因此强制规则比团队默契更重要。

编码标准（PSR-12）

• 必须遵守 PSR-12（扩展编码风格），这包括缩进（4空格）、命名空间、类名（PascalCase）、方法名（camelCase）、常量（大写）等。
• 自动化工具：使用 PHP_CodeSniffer 或 PHP-CS-Fixer 进行强制检查。

  # 在 Git 提交前自动运行
  vendor/bin/php-cs-fixer fix src --dry-run --diff

静态代码分析（PHPStan/Psalm）

• 这能发现潜在的逻辑错误（如类型不匹配、方法不存在）。
• 推荐使用 PHPStan，级别建议在 Level 5 或 Level 6（能发现大部分问题且不至于太难改）。
• 将其配置在 CI（持续集成）中，未通过检查的代码不能合并。

---

架构与协作模式

前后端分离 vs 服务端渲染

• 若后端纯 API：建议全团队共用一套 API 规范（RESTful 或 GraphQL），并使用 OpenAPI（Swagger） 生成文档，让前端和后端并行开发。
• 若服务端渲染（Blade 模板）：前端 UI 部分建议明确定义路由和控制器职责，避免互相冲突。

代码分层（MVC / 服务模式）

• 避免在控制器（Controller）里写大量业务逻辑（Fat Controller）。
• 推荐模式：
  • Model：数据交互。
  • Service：核心业务逻辑（OrderService）。
  • Repository：数据查询层（可选，适合复杂查询）。
• 好处：多人开发时，A 可以写 Controller，B 可以写 Service，冲突较少。

数据库迁移（Migrations）

• 绝不允许手动改数据库,必须使用 Migrations（Laravel 的 php artisan make:migration）。
• 重要：修改表结构也必须是新的迁移文件，不能修改旧的迁移文件（除非项目未上线）。
• 配合 Seeders 生成测试数据，方便新同事快速启动。

---

工作流（Pull Request + Code Review）

这是保证代码质量和知识共享的关键。

1. 开发前：
   • 从最新的 develop 分支创建新分支。
   • 使用任务管理工具（Jira / Trello / GitHub Issues）关联任务编号。
2. 开发中：
   • 频繁提交代码（小步提交，逻辑独立）。
   • 运行本地测试。
3. 开发后：
   • Push 代码到远程仓库。
   • 发起 Pull Request（PR / MR） 到 develop 分支。
4. Code Review（代码审查）：
   • 必须至少 1 人 Review 后才能合并。
   • 检查点：逻辑正确性、安全性（SQL注入、XSS）、性能（N+1查询）、代码风格。
   • 使用 GitHub/GitLab 的 “Comment” 功能进行讨论，不要直接点击合并（除非是小改动）。

---

测试（CI/CD）

• 单元测试（PHPUnit）：核心业务逻辑必须有测试（计算器、订单状态机）。
• 集成测试：数据库交互、API 端点。
• 配置 GitHub Actions 或 GitLab CI：
  1. composer install
  2. php -l （语法检查）
  3. vendor/bin/phpunit （跑测试）
  4. vendor/bin/phpstan analyse （静态分析）
  5. vendor/bin/php-cs-fixer fix --dry-run （代码风格）

---

PHP 项目特有的合作“坑”与对策

这是 PHP 合作中特别容易遇到、需要留意的地方：

1. 配置冲突：

   • 问题：.env 文件每个开发人员都不同（数据库账号）。
   • 对策：将 .env.example 放入 Git，自己本地复制为 .env 修改，永不提交 .env 到 Git。
   • 进阶：不要用全局变量（如 $GLOBALS），统一使用容器或配置类。

2. 扩展冲突：

   • 问题：某个 PHP 扩展（如 redis、xdebug）有的人装了，有的人没装。
   • 对策：代码中减少对特定扩展的强依赖，或者通过 Docker Compose 配置好 Dockerfile，所有人用同一套环境。

3. 文件编码：

   • 问题：老项目可能是 GBK 编码，新开发是 UTF-8，导致乱码。
   • 对策：全项目统一 UTF-8（无 BOM）。

4. Composer 锁版本：

   • 问题：A 更新了依赖，B 没更新，导致行为不一致。
   • 对策：修改 composer.json 后，必须跑 composer update 并提交 composer.lock，其他人必须跑 composer install（严格模式）。

---

推荐 PHP 项目团队工作流（实操案例）

假设使用 Laravel 框架（最常见的 PHP 框架）：

• 周一： 开会，从 Jira 认领任务。
• 在你的电脑上：

  git checkout develop
  git pull origin develop
  git checkout -b feature/login-v2

• 写代码（2小时）： 实现功能，写测试。

  php artisan make:test LoginTest

• 本地检查（确保绿灯）：

  composer test   # 统一封装了 phpunit
  composer lint   # php-cs-fixer

• 提交与推送：

  git add .
  git commit -m "feat: 完成登录V2版逻辑"
  git push origin feature/login-v2

• 在 GitHub： 打开 Pull Request，关联 Issue，@ 队友好。
• 队友 Review： 发现 N+1 查询，提出建议。
• 你修改： 推送新 commit 到同一分支。
• 合并： 通过 CI 检查，队友 Approve，合并到 develop。
• 部署： 当 develop 稳定后，合并到 main 触发自动部署。

---

PHP 项目合作的三驾马车：

1. Git（分支管理）：明确工作流，避免“死磕”代码。
2. Composer + Docker（环境一致）：确保“在我电脑上能跑”变成“在哪都能跑”。
3. CI + PHPStan（自动化检查）：在机器层面替人类把关代码质量。

只要把这三点做到位,PHP 的合作也可以非常顺畅高效，建立团队共识：“提交干净的代码，不要随手丢垃圾代码让队友去填坑”。