当前位置:  首页  >  PHP教程  >  PHP 基础  >  开发经验

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

想问一下各位使用Composer的同学,通过Composer下载后的文件你们会把内容提交到Git上吗?在官方的Faq上看到ShouldICommitthedependenciesinmyvendordirectory这篇文章,有建议是不提交到Git,那么应该如...
想问一下各位使用Composer的同学,通过Composer下载后的文件你们会把内容提交到Git上吗?
在官方的Faq上看到Should I Commit the dependencies in my vendor directory这篇文章,有建议是不提交到Git,那么应该如何处理切换分支就要重新composer install这个问题呢?如果将vendor提交到版本库,那又应该如何处理包里面带有的.git文件夹呢?

*修正 composer update 应该为 composer install

回复内容:

想问一下各位使用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 文件,记录了依赖库产生任何改动之后,项目中所有依赖库的具体版本。请阅读关于此文件的文档。

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


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

如果提交:

  1. 优势:“拉取即用”的便利。

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

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

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

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

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

(1)务必保证vendorcomposer.lock这两个文件的提交是同步的。提了一个,必须提另一个。
任何开发,如果任何一次 commit 只交了其中一个,必须追责。
这个的理由是:虽然我们提交vendor保证拉取下来立刻可用,但是 git 是有部分检出(checkout)功能的 —— 对于一个 Composer 项目,我有权遵照 Composer 项目的惯例,不检出vendor目录,而是拉取下来实务代码之后随手一个composer install,你不能说我错。
(如果谁说这个是错的,我支持你分分钟上sf和知乎曝光你的无良公司和技术主管)

(2)务必按照Composer对于提交vendor文件夹的建议,忽略掉子库的所有.git目录,只提交vendor中的实务代码。
相信我,vendor中的实质代码,和vendor/**/.git下git库本身的管理用文件,绝对是冰山的水上部分和水下部分的关系。不忽略,会死人的,不夸张。


另外必须指出的是:分支开发时,就算不通过版本库同步vendor,而只同步composer.lock,也不会造成时间的浪费。

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

这个可以参考GitHub上的Laravel项目,https://github.com/laravel/laravel。

.gitignore文件:https://github.com/laravel/laravel/blob/master/.gitignore

也是很明显的不提交vendor文件夹。

首先如果你重来没有提交过 vendor 目录,切换分支也不需要 update,
其次正常情况下 vendor 下面的包是不带 .git 文件夹的。

至于需不需要提交 vendor 到git,这得看情况。
如果你是发布一个公开项目到 github,显然不需要提交,写好 composer.json 就可以了。
如果是私有项目,这看你是如何发布的。如果是打包,然后解压到服务器,可能需要提交,如果有更自动化的流程,比如自动更新,自动update,那你也可以不提交。

看你希望怎么管理项目,这方面没有定论,不过一个建议是应该把第三方库的版本依赖写确切,不要写通配,正常情况下也不要用composer update,第三方库又没问题为什么要update?除非你确实遇到第三方库当前版本有bug需要升级,或者你的新功能要依赖第三方库新版本的特性,不然你莫名其妙update干嘛?

一个准则,在开发任何新特性之前,第三方库的版本依赖就应该是确定的,这方面不能有含糊的地方,不然你这项目管理就是有问题了。

既然第三方库的版本确定,那么推不推vendor就是另外的问题了,如果你懒得部署时再install,那么大可以直接就推去远程把第三方库当成项目的一部分,这也是比较推荐的做法,因为打包捆绑的好处就是分发方便,这方面我是支持不忽略vendor的,当然更大的原因是天朝的网络……实在没法每次都重复等,妈蛋等啊等再好的撸码好心情也要等坏啊……

吐了个 "CAO" !
扫码关注 PHP1 官方微信号
PHP1.CN | 中国最专业的PHP中文社区 | PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | PHP问答
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved PHP1.CN 第一PHP社区 版权所有