再说 vendor 目录进不进版本控制

先说结论:不进 官方的指导是不进,如果非要进有如下四个方法 尽可能使用已经发布的包,这样可以使用tarball的方式来更新。 在composer.json中指定preferred-install为dist或者更新的时候带上–prefer-dist参数 在提交git/svn之前,删除掉所有.git目录 在项目的.gitignore中加上/vendor/**/.git 为什么我又来发这个了呢,因为我踩到坑了啊,由于使用了private package在composer.json中加了repositories,结果vendor下这些内容都成了submodule,但是远端的并不会更新,所以这是一个很严重的问题。 至于以后的部署问题,我还要再梳理一下。

vendor 目录究竟应不应该进 VCS

很多项目现在都有组件式的包管理,比如 composer 管理的第三方组件都存放在 vendor 目录下,那么究竟这个目录应不应该放到 git 之类的版本管理里去,之前我的做法是不放,但是后来发现了一个问题,当多台机器面临更新第三方组件的时候,会出现版本不一致的问题,而且本身 Laravel 的 config/app.php 中启用了第三方组件,但是 vendor 目录中还需要 composer update 更新的时候就会报错; 所以,vendor 作为整个项目的一部分,应该放进版本控制系统(VCS);在部署打包的时候也是一份子,编译打包进入 Docker 之类的容器,进行整体的部署,也才能够保障每个服务器上运行的代码是一致的; Update: 2016-11-02 10:06 把vendor目录放进版本控制系统也遇到了一些更有意思的问题,比如require-dev中的内容也一并进入了版本控制,进而进入了线上环境,虽然问题不严重,但是终究觉的这不”清真“了。 更理想的做法应该是vendor不进VCS,把这些事情都交给CI系统来做,线上部署的机器应该是统一由CI系统打包的结果,开发环境(自行update)->CI(自动update并打包)->仿真环境(不更新直接部署CI的包)->生产环境(同仿真环境)。