composer package

遇到过相同的问题, 我的解决方案是在 `.gitignore` 文件里面把 `composer.lock` 这一行去掉, 也就是说把 `composer.lock` 文件也加入版本控制.

这样做有以下好处:

让参与项目开发的成员使用这些 package 的同一版本, 减少分歧;
在生产环境下, 使用命令 `composer install` 可以确保跟开发的时候使用了统一的版本, 减少不必要的变数;
跟踪当前项目使用所有 `package` 的版本, 当执行 `composer update` 出现问题时, 可以利用 Git 定位到出问题的 package, 匹对下版本, 接下来就可以做如: 在 composer.json 里面写死版本等的解决动作了.
注意: 这里说下 composer 的机制, 当 `composer.lock` 文件存在的时候, 执行 `composer install` 命令时, composer 会更新按照 `composer.lock` 里的 package 指定版本进行安装, 如果是执行 `composer update` 的话, 会更新 `package` 版本, 并更新 `composer.lock` 文件.
最后一条好处尤其重要, 设想如果是在没有版本控制 `composer.lock` 文件的情况下, 一出现问题, 那就直接瞎眼了.

---

　　安装的是 monolog 1.1 版本，而一个多月以后的现在，monolog 已经是 1.2 了，运行命令后直接更新到 1.2，这时项目并没有针对 1.2 进行过测试，项目一下子变得很不稳定，情况有时候会比这个更糟糕，尤其是在一个庞大的项目中，你没有对项目写完整覆盖测试的情况，什么东西坏掉了你都不知道。
那应该使用哪个命令呢？install, update 还是 require ？

接下来我们一一解释。
简单解释
composer install - 如有 composer.lock 文件，直接安装，否则从 composer.json 安装最新扩展包和依赖；
composer update - 从 composer.json 安装最新扩展包和依赖；
composer update vendor/package - 从 composer.json 或者对应包的配置，并更新到最新；
composer require new/package - 添加安装 new/package , 可以指定版本，如： composer require new/package ~2.5.