composer下载的内容需要提交到git吗

这篇文章主要为大家展示了“composer下载的内容需要提交到git吗”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“composer下载的内容需要提交到git吗”这篇文章吧。

创新互联是专业的乡宁网站建设公司，乡宁接单;提供成都网站建设、网站建设,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行乡宁网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!

具体问题：

想问一下各位使用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 文件，记录了依赖库产生任何改动之后，项目中所有依赖库的具体版本。请阅读关于此文件的文档(https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file)。

你应当永远把composer.lock文件提交到版本库，并在切换分支或部署之后，使用composer install安装 lock 文件中指定的具体依赖版本。

从这个意义上讲，你是否将vendor目录提交到主版本库都是对的。提交与否这是一个互有取舍的选择：

如果提交：

优势：“拉取即用”的便利。

劣势：信息重复。因为你开发当时的具体版本，lock 文件已经记录。也就是说vendor文件夹表述了同一件事情。

劣势：引入不一致性的风险。因为虽然 Composer 保证 lock 文件和vendor目录一致，但提交到 git 版本库毕竟是一个人工行为。你难以保证哪一次不会落下二者之一。

如果不提交，优劣势反过来。不再重复。

我的想法是：我建议你坚持“正确性优于易用性”的思想。我的建议是不提交vendor，仅仅使用 lock 文件维持开发当时的依赖库版本。

如果提交的话，请务必遵循以下两个准则：

（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，也不会造成时间的浪费。

两个分支切换时，无非是两套具体版本换来换去。而 Composer 本身对所有下载的库都是缓存的。每次拉分支之后的composer install必然命中全部的缓存，而不需要重复消耗下载的时间。

以上是“composer下载的内容需要提交到git吗”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！