PHP开发者的Git工作流程：如何不搞崩生产环境

PHP开发者的Git工作流程：从混乱到有序（再回来）

您是否曾在周五晚上将代码推送到master分支，祈祷一切顺利？或者在使用composer.lock时踩过坑，合并后一切崩溃？欢迎加入这个俱乐部。Git不仅仅是一个版本控制系统，它是您的日常工具。但没有正确的工作流程，即使最酷的PHP代码也会变成南瓜。

在本文中，我们将解析一个真正适用于PHP开发者的Git工作流程：从选择分支策略到部署。没有废话，只有代码、示例和技巧。开始吧！

1. 选择策略：Git Flow vs. Trunk-Based

Git flow和trunk-based development之间的争论比PHP框架的历史还要长。但对于大多数PHP项目（尤其是基于Symfony/Laravel的遗留项目），Git Flow仍然是黄金标准。为什么？

\n
• 清晰的隔离：功能、发布和热修复的隔离。
\n
• 控制：对发布到生产环境的内容有控制权。
\n
• 与Composer协作：无需每次都合并dev分支。
\n

但如果您的项目是微服务并且CI/CD非常强大，trunk-based也是一个选择。我们将专注于经典方案。

2. 功能分支：您的沙盒

每个新功能都对应一个独立的分支。名称应该具有描述性：feature/PROJ-123-add-payment-gateway。不要使用fix-bug或new-stuff这样的名称。

开始工作的示例：

git checkout -b feature/PROJ-42-new-cache-system develop\ngit push origin feature/PROJ-42-new-cache-system

在编写代码时，别忘了Composer。如果添加了新的依赖项，请将composer.json和composer.lock一起提交。这将拯救您的同事，避免出现“为什么我这边不行？”的情况。

composer require predis/predis\ngit add composer.json composer.lock\ngit commit -m "PROJ-42: Add predis for caching"

重要提示：不要提交vendor/目录！立即将其添加到.gitignore中。

3. 拉取请求：无痛代码审查

当功能完成后，您需要创建一个指向develop分支的PR（或在GitLab中称为MR）。以下是一个检查清单，可以节省审查者的精力：

\n
• ✅ 代码通过phpcs和phpstan检查（至少达到6级）。
\n
• ✅ 编写了测试（PHPUnit, Pest）。
\n
• ✅ 更新了composer.lock。
\n
• ✅ 与develop分支无冲突。
\n

CI脚本示例（GitHub Actions）：

name: PHP CI\n\non:\n  pull_request:\n    branches: [ develop ]\n\njobs:\n  php-tests:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - name: Install dependencies\n        run: composer install --no-interaction --prefer-dist\n      - name: Run PHPStan\n        run: vendor/bin/phpstan analyse src --level=6\n      - name: Run tests\n        run: vendor/bin/phpunit

这个面向PHP开发者的工作流程在有人查看PR之前就自动化了代码检查。很神奇，对吧？

4. 发布分支：准备生产环境

当积累了足够的功能用于发布时，从develop分支创建release/x.y.z分支。在这里，您修复错误、更新变更日志、在composer.json中升级版本号。

git checkout -b release/1.2.0 develop\n# 修复错误，更新版本号\nvim composer.json  # 将 "version" 改为 "1.2.0"\ngit commit -am "Bump version to 1.2.0"\n# 合并到 master 和 develop 分支\ngit checkout master\ngit merge --no-ff release/1.2.0\ngit tag -a v1.2.0 -m "Release version 1.2.0"\ngit push origin master --tags

请注意--no-ff参数。这可以保留分支历史，让您始终知道代码来自哪里。