这可能是一个非常天真的问题，但我正在努力理解Git的子树和Composer对PHP的依赖管理之间的实用性差异。在转储Git子模块后，我开始使用Git子树。但是现在有了Composer(用于PHP)。由于我的大多数项目都是基于PHP的，我正在考虑放弃子树，转而使用Composer。
例如，我有多个Wordpress网站。我想拉Wordpress本身和我想使用的插件。我可以用Git子树和Composer来实现这一点，对吧？
如果我没有在子文件夹上游提交/推送代码的用例，但只想将最新/特定版本拉入子文件夹，那么Subtree和Composer是否提供了相同的实用程序？
在我的用例中，我觉得Composer比Git子树更容易使用，更容易在子文件夹中获得另一个/更新版本的脚本，而无需将那些提取的子文件夹文件提交到Git repo中。
对我的理解有什么想法吗？这种策略有问题吗？或者他们两个完全不同，没有任何相似之处？
有很多原因支持Composer。
实际上，它管理整个项目和供应商库本身的依赖关系。因此，如果你需要一个包，它会得到所有需要的东西或通知你错误。
管理版本也很简单，因为对于您下载的每个软件包，您都可以指定它应该更新到的版本(因此您可以决定只更新软件包的小版本，或者使用dev-master进行全面更新)
Composer也为自动加载提供了一些帮助。使用-o运行时使您的项目更快
使用仅限开发的软件包还可以更轻松地管理生产设置。
若供应商提供了composer功能，我几乎并没有理由使用子模块。