到底这个 composer.lock 和 vendor 该怎么弄，有下面几种情况

1. composer.lock 和 vendor 都提交到代码库，然后就没有然后了。
2. composer.lock 和 vendor 都不提交，使用composer update 安装和更新
3. 忽略composer.lock，不提交vendor目录，使用composer update 安装和更新

不知道为什么，周围很多人都这么用，全都说不出个为什么，但是就是觉得这样是对的，因为他也没遇到过什么大问题。

那么 composer 安装完了以后，到底提不提交 composer.lock，和 vendor 目录呢？

composer.lock

这里 http://docs.phpcomposer.com/01-basic-usage.html#composer.lock-The-Lock-File 有详细的介绍，用来锁定我们安装的包版本的。

vendor

通过 composer 下载的各种第三方的包，都会在 vendor 目录里面。

正确的方式是提交 composer.lock，但是不提交 vendor 目录，使用composer install 安装第三方依赖

举个例子

• 比如有一天突然要写一个 laravel 项目，于是我配置了 composer.json 文件，指定了 "laravel/framework": "5.1.*"，这个时候 larval 最新的版本是 5.1.4，执行 composer install， larval 5.1.4 被下载到 vendor 目录中，同时生成了 composer.lock 文件，lock 文件中锁定了使用 laravel 5.1.4。我开始了愉快的开发，并把 composer.json 和 composer.lock 两个文件提交到代码库里面。
• 一段时间以后，需求越来越多，让同事们帮我完成吧，于是他们 clone 了代码，执行 composer install，因为有composer.lock文件的存在，自然他们下载的也是5.1.4。大家的代码都是一致的，绝对没有问题
• 项目差不多了，测试一下吧，于是，运维人员把代码部署到服务器，执行了composer install ，同样的，也是 5.1.4 。本地，同事，服务器的代码都一致，完全没毛病。
• 但是其实这个时候 laravel 已经更新到了 5.1.7 并且解决了一个很重要的bug。我发现了这个问题，作为项目的负责人，我决定升级laravel，于是我在本地执行了composer update laravel/framework，这时 laravel 5.1.7 被下载到 vendor 目录中，同时 composer.lock 更新了锁定说明为 5.1.7。我只需要提交 comopser.lock即可。同事们更新了代码，同样只是执行 composer install，运维人员同样也是更新代码，composer install。

总结

有了 composer.lock 的保障，所有通过 composer install 下载的包绝对是一样的，那么当然就没有必要提交 vendor 目录。composer update 应该交给指定的人更新，更新完了要测试，毕竟是第三方的库，不能保证他完全正确，又或是版本指定错了等等不确定因素吧。