git是php项目事实上的标准版本控制工具，因其分布式架构契合php生态的分支隔离、本地提交、历史重写及ci/cd自动化需求，而svn和mercurial因集成度低、社区支持弱被边缘化。
Git 是当前 PHP 项目事实上的标准版本控制软件，没有之一。它不是“PHP 专用”，但所有主流 PHP 工具链（Composer、Laravel、Symfony、PhpStorm、VS Code）都深度集成 Git，且绝大多数开源 PHP 项目托管在 GitHub/GitLab 上。
为什么 PHP 项目几乎只用 Git，而不是 SVN 或 Mercurial
PHP 生态的协作模式高度依赖分支隔离、本地提交、快速重写历史和 CI/CD 自动化——这些正是 Git 的强项。SVN 虽然仍被少数传统企业项目使用，但它的集中式架构导致以下实际问题：
- 离线无法提交或查看完整日志
- 分支创建/合并成本高，团队常因此回避特性分支实践
- 与 Composer 的
pathrepository 或package替换机制配合生硬 - GitHub Actions、GitLab CI 等现代流水线不原生支持
SVN触发
而 Mercurial 在 PHP 圈几乎无实际存在感：主流 IDE 不提供开箱即用支持，社区教程、CI 模板、框架文档全部默认以 Git 为前提。
git init 后必须做的三件事（PHP 项目特有）
刚初始化仓库时，别急着 git add .。PHP 项目有几类文件/目录必须明确排除，否则会引发权限、安全或 CI 失败问题：
- 把
vendor/加入.gitignore—— Composer 依赖由composer.lock锁定，重复提交vendor/会导致 diff 巨大、PR 难审、CI 构建变慢 - 忽略
.env和*local.php类配置文件 —— 防止密钥、数据库密码意外泄露；用.env.example提供模板 - 排除
storage/logs/、bootstrap/cache/（Laravel）或var/cache/（Symfony）等运行时生成目录 —— 这些内容每次部署都会重建，提交进去反而干扰 diff
PHP 开发中容易被忽略的 Git 实操细节
很多 PHP 开发者会用 git clone 和 git push，但遇到真实协作场景就卡住。下面几个点直接影响日常效率：
立即学习“PHP免费学习笔记（深入）”；
-
git commit -m写得含糊（如“fix bug”）？建议统一用 Conventional Commits 格式，比如fix(auth): prevent token reuse after logout—— 这能让composer install时的changelog生成、自动语义化版本发布（viaphp-scoper或roave/backward-compatibility-check）真正可用 - 切换 PHP 版本（如用
phpbrew switch 8.2）后，别忘了检查php -v和which php—— 否则git hooks（如pre-commit调用phpstan）可能跑在错误版本上，报出误报的类型错误 - 在
git rebase -i中 squash 提交时，注意不要合并含composer update的提交 —— 因为composer.lock的哈希值对每个 commit 是确定的，强行 squash 会导致 lock 文件冲突或不可重现的依赖状态
composer.lock、.gitignore 和提交信息共同构成可验证、可回滚、可协作的最小闭环。这点比选哪个 GUI 客户端重要得多。 
