1.现在都持续集成持续部署了，都是交付的制品到生产环境。肯定不跟踪node_module vendor的。

看到你说 vendor 和 composer.json 必须保持一致，我就笑了，你根本就不熟悉 composer 机制，熟悉了之后，vendor 只会跟 composer.lock 保持一致。为了项目长远稳健发展，vendor 和 composer.lock 都不能加到版本控制里面，这样做可以保障用到的第三方包是最前沿的，没有 BUG 的，bug包含很多，有安全性的等等。

@tu6ge-php 我的意思是 vendor 和 composer.json 是所有分支都必须保持一致 ，不是 vendor 跟composer.json 一致

@widdy 那我本地引用了新的包，推送线上，线上又要重新 composer install 吗

个人认为vendor不追踪，而composer.lock看情况，如果是多人协作开发，最好追踪，他人按照 .lock 文件安装即可，这样不会出现由于安装包的小版本差异，导致一个人运行报错，而另一个人不报错。

(当然，小版本如 5.1.10 和5.1.12 这种小版本会出现一个报错另一个不报错的情况，很罕见，所以也可以不追踪，看自己了)

关于楼主的.gitignore 中 storage 文件夹的管理，也可以在 app、logs 等文件夹下加入 .gitignore 单独管理，具体参见laravel 官方项目的写法。

@LuminEe 如果不追踪，生产环境的 vendor 怎么同步，composer 可是会使用到很多禁用函数的

vendor & node_modules

composer install 还可以 检查环境 的情况 (比如某些 扩展 没安装,php 版本不符等)。

有时候为了 懒惰, vendor 提交能理解。

node_modules 这个就离谱了,我可能会认为故意 搞事情…

理由:

1. 文件很大,远超vendor,造成仓库太大。
2. 对于生产环境,node_modules 没用。
3. 对于其他人的环境,也不确定是否可以使用, npm i 也同样可以作为检查环境。

关于生产的危险函数:

php -d php_composer.ini /usr/local/bin/composer install

(单独创建一个 php 的配置给 composer 用)

@lyxxxh 受教了

vendor 不应该提交到 git，理由罗列：

• vendor 库在开发和线上时会有微妙的区别，开发会多出一些调试库，在 require-dev 里，这些是 不应该 被 install 到生产环境的。
• 要保证扩展库版本一致可以通过提交 composer.lock 文件到 git，这是推荐做法。
• 接入 CI/CD ，composer install 在构建阶段就完成了，打包后推送到生产环境，生产环境不需要安装 composer；一般情况下，此时 install 也需要加上一些参数，例如 composer install --optimize-autoloader --no-dev

你把 /storage/*.key 排除了。你每次部署你前台登录的用户都会掉线

composer的vendor 和 node的 node_modules 线上都不需要。这些流程基本上都能直接通过 CI系统持续构建的时候完成，生产环境基本上不装composer、npm这些东西。也不会在线上直接用composer拉依赖

兄弟可知什么是CICD?

@Larva 是不是搞了什么骚操作 你可以去装个初始化新项目 默认key就是忽略的

其实laravel的artisan command也用了proc_open函数，按照兄弟的说法，也应该禁用。

默认不代表就是正确的，默认项目是为了初次安装，不是长期滚动更新。

@lyxxxh 建议很有用，指正一点，php -d 是临时单项配置，php -c php.ini 才是指定配置文件

请问一下，如果是在内网环境下，根本无法联网的环境，如何部署。

:joy: 我现在的方案是 在联网环境，下载好依赖，导出镜像，进入内网导出镜像，再构建。 请问还有其他更好的方式吗。

我是不忽略 vendor , 因为生产环境拉包贼慢，影响部署速度 。