.gitignore的使用---vendor是否应该追踪

vendor node_module 都应当被追踪.

我个人认为的追踪原则:

  1. 所有静态文件都应当被追踪,比如: node_module vendor
  2. 所有动态文件及环境变量都应当被忽略,比如:.env storage/framwork storage/cache storage/views
  3. 环境变量都应当提出到 .env,而 config/* 应当不被编辑
  4. 不管有几个测试分支,node_module vendor composer.json 都应当保持一致

这么想的原因是:生产环境的注重安全性,生产环境并不应该安装composer,因为composer需要使用proc_open等危险函数

下面是我用的 .gitignore

/storage/*.key

/storage/app/

/storage/debugbar/

/storage/framework/

/storage/logs/

.htaccess

.env

/public/.user.ini

有什么不对的地方,还望各位大佬指正

本作品采用《CC 协议》,转载必须注明作者和本文链接
reading
白小二
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 18

vendor 不应该提交到 git,理由罗列:

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

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 用)

2年前 评论

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

2年前 评论

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

2年前 评论
小李世界 2年前
arukas 2年前
tu6ge-php (作者) 2年前
白小二 (楼主) 2年前
白小二

@tu6ge-php 我的意思是 vendorcomposer.json 是所有分支都必须保持一致 ,不是 vendorcomposer.json 一致

2年前 评论
白小二

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

2年前 评论
widdy 2年前

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

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

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

2年前 评论
白小二

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

2年前 评论

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 用)

2年前 评论
白小二

@lyxxxh 受教了

2年前 评论

vendor 不应该提交到 git,理由罗列:

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

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

2年前 评论
arukas 2年前
xianyunyehe

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

2年前 评论
fatrbaby

兄弟可知什么是CICD?

2年前 评论

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

2年前 评论
fatrbaby

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

2年前 评论

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

2年前 评论
白小二

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

2年前 评论

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

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

2年前 评论
Tsukasa_Kanzaki 2年前
鲜橙多 (作者) 2年前
Tsukasa_Kanzaki 2年前

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

2年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!