WWW.lllT.neT下边由composer实例教程频道给各位讲解有关composer下载的具体内容要不要递交到git的问题,期待对必须的小伙伴有些协助!

实际问题:

想问一下诸位应用Composer的同学们,根据Composer下载后的文档你们会把具体内容递交到Git上吗?
在官方网的Faq上见到Should I Commit the dependencies in my vendor directory这篇文章,有提议不是递交到Git,那麼应当如何处理切换分支就需要重新composer install这个问题呢?假如将vendor递交到版本库,那又应当如何处理包里边含有的.git文件夹名称呢?

*调整 composer update 应当为 composer install

解决方案:

实际上不论是支系开发设计,或是布署到工作环境,不管composer.json中版本信息的使用通配符标准你怎么写,大家最在意的始终是一个最压根具体内容:开发设计那时候,大家用的全部依靠库,实际的版本信息是哪一个?

而这一具体内容是composer.lock文档适用的。composer 自身根据维护保养 lock 文档,纪录了依靠库造成一切修改以后,新项目中全部依靠库的主要版本号。请阅读文章有关此文档的文本文档(http://www.lllt.net/img/20211203/dobftpsopvy.md install安装 lock 文档中特定的实际依靠版本号。

从这一实际意义上讲,你是不是将vendor目录提交到主版本库全是对的。递交是否这是一个互有选择的挑选:

假如递交:

优点:“获取即用”的便捷。

缺点:信息内容反复。由于你开发设计那时候的主要版本号,lock 文档早已纪录。换句话说vendor文件夹描述了同一件事情。

缺点:引进不一致性的风险性。由于尽管 Composer 确保 lock 文档和vendor文件目录一致,但递交到 git 版本库终究是一个人力个人行为。你无法确保哪一次不容易落下来二者之一。

如果不递交,优势与劣势相反。不会再反复。

我的想法是:我建议你坚持不懈“准确性好于便捷性”的观念。我们建议不是递交vendor,只是应用 lock 文档保持开发设计那时候的依靠库版本号。

假如递交得话,请尽量遵循下列2个规则:

(1)尽量确保vendor和composer.lock这两个文档的递交是同时的。提了一个,务必提另一个。
一切开发设计,假如每一次 commit 只交了在其中一个,务必追究责任。
这一的原因是:尽管我递交vendor确保获取出来马上可以用,可是 git 是有一部分验出(checkout)作用的 —— 针对一个 Composer 新项目,我有权利遵循 Composer 新项目的国际惯例,不验出vendor文件目录,反而是获取出来操作实务编码以后随意一个composer install,你不能说我的错。
(假如为什么说这个是错的,我支持你一下子上sf和知乎问答曝出你的缺德企业和技术总监)

(2)尽量依照Composer针对递交vendor文件夹的提议(https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md),忽视掉子库的全部.git文件目录,只递交vendor中的操作实务编码。
相信自己,vendor中的本质编码,和vendor/**/.git下git库自身的管理方法用文档,肯定是冰川的海上一部分和水中一部分的关联。不忽视,会死尸的,不浮夸。

此外需要强调的是:支系开发设计时,即使不通过版本库同歩vendor,而只同歩composer.lock,也不会导致時间的消耗。

2个支系转换时,无非是两个实际版本号变来变去。而 Composer 自身对全部在线下载的库全是缓存文件的。每回拉支系以后的composer install必定击中所有的缓存文件,而不用反复耗费在线下载的時间。

以上便是composer下载的具体内容要不要递交到git呢?的详尽具体内容,大量请关心自学java网其他相关文章!

WWW.lllT.neT

声明:有的资源来自网络转载,版权归原作者所有,如有侵犯到您的权益请联系邮箱:our333@126.com我们将配合处理!

原文地址:composer下载的具体内容要不要递交到git呢?发布于2021-12-12 09:36:02