这可能是一个非常天真的问题,但我试图理解Git的Subtree和PHP的Composer依赖管理之间的效用差异.在转储Git子模块后我开始使用Git Subtrees.但现在有Composer(用于PHP).由于我的大部分项目都是基于PHP的,我正在考虑转储Subtrees以支持Composer.
例如,我有多个Wordpress站点.我想拉Wordpress本身和我想要使用的插件.我可以用Git Subtrees和Composer实现这一点,对吗?
如果我没有用例在上游子文件夹中提交/推送代码,但只希望将最新/特定版本提取到子文件夹中,那么Subtree和Composer是否提供相同类型的实用程序?
在我的用例中,我觉得Composer胜过Git Subtree更容易使用,更容易在子文件夹中获得另一个/更新版本的脚本,而不会将这些拉出的子文件夹文件提交到Git repo中.
对我的这种理解的任何想法?这种策略有问题吗?或者两者完全不同,没有任何相似之处?
有很多理由支持Composer.
它实际上管理整个项目和供应商库本身的依赖关系.因此,如果您需要一个包,它将获得所有必需的东西或通知您有关错误.
管理版本也很简单,因为您下载的每个软件包都可以指定它应该更新的版本(因此您可以决定仅更新软件包的次要版本或使用dev-master完全更新)
Composer也提供了一些自动加载的帮助.运行时让您的项目更快一点-o
只有开发包也可以让您更轻松地管理生产设置.
如果供应商提供了作曲家功能,我发现没有理由使用子模块.