用 git 管理 PHP 项目比手动打包更可靠，需配合 .gitignore、合理分支策略、提交 composer.lock、明确 PHP 版本、用 git archive 部署并验证一致性。
用 git 管理 PHP 项目比手动打包靠谱得多
PHP 本身不提供版本控制能力，所谓“PHP 版本控制”实际是用 git 管理 PHP 源码。很多团队还在靠复制文件夹、改名加日期（如 api_v2_20240510）来“版本化”，这会导致回滚困难、协作冲突、部署混乱。直接上 git 是最轻量也最有效的起点。
实操建议：
- 初始化时加
.gitignore，至少排除vendor/、composer.lock（若多人协作需保留）、logs/、cache/和环境配置文件（如.env） - 分支策略别搞太复杂：日常用
main（或master）保稳定，功能开发走feature/xxx，热修走hotfix/xxx - 每次提交前跑一次
composer install --dry-run，避免composer.lock意外变更导致依赖不一致
composer 锁定依赖版本比写死 require 更可靠
在 composer.json 里写 "monolog/monolog": "^2.0" 看似灵活，但不同人执行 composer install 可能装出 2.1.1 或 2.9.0——小版本差异有时会触发静默行为变更。真正可控的是 composer.lock 文件。
关键点：
立即学习“PHP免费学习笔记（深入）”；
-
composer.lock必须提交进git，不能忽略 - 上线前务必确认
composer install（不是update）——后者会重算并覆盖lock文件 - 升级依赖时，先在开发环境跑
composer update monolog/monolog，验证无误再提交新的lock文件 - CI 流水线中加检查：用
composer validate --strict防止composer.json格式或约束错误
PHP 运行时版本差异会让 git diff 失效
同一个 PHP 代码，在 PHP 7.4 和 PHP 8.2 下可能因语法兼容性（如属性类型声明、match 表达式）或函数行为（如 json_encode() 对资源的处理）产生不同输出。这时光看 git diff 发现不了问题，得靠运行时验证。
应对方式：
- 在
.php-version或 CI 配置里明确声明目标 PHP 版本，比如 GitHub Actions 中用actions/setup-php@v4指定php-version: '8.2' - 本地开发用
php -v和php --ini确认 CLI 使用的确实是预期版本，Apache/Nginx 的 PHP 模块版本可能不同 - 在
composer.json的config.platform.php字段声明最低要求（如"8.1"），让composer install提前报错，而不是运行时报错
部署时跳过 git pull 直接用 git archive 更干净
生产环境执行 git pull 看似方便，但会把 .git 目录、未跟踪文件、临时分支全带上去，既占空间又增加攻击面。更稳妥的做法是用 git archive 导出纯净快照。
示例命令：
git archive --format=tar.gz --output=deploy-$(git rev-parse --short HEAD).tar.gz main
然后解压到 Web 根目录。这个包不含任何 Git 元数据，也不依赖服务器装 Git，还能天然规避 .gitignore 之外的敏感文件泄露风险。
注意点：
- 如果项目依赖
composer install生成的自动加载文件，得在打包前先运行（或在部署脚本中补上） -
git archive不包含子模块内容，如有 submodule，得单独处理或改用git subtree - 标签（tag）比分支名更适合归档：用
git archive -o release-v1.3.0.tar.gz v1.3.0，语义更清晰
真正的效率瓶颈往往不在工具本身，而在是否让版本号和运行环境、依赖、部署产物之间形成可验证的一致性链路。漏掉任意一环，都可能让“版本控制”变成“版本幻觉”。
