Git子树和作曲家

这可能是一个很天真的问题，但我想了解Git的Subtree和Composer依赖管理PHP之间的效用差异。在转储Git子模块后，我开始使用Git子树。但现在有Composer（用于PHP）。由于我的大部分项目都是基于PHP的，我正在考虑倾销Subtrees转而使用Composer。Git子树和作曲家

例如，我有多个Wordpress网站。我想拉动Wordpress本身和我想要使用的插件。我可以通过Git Subtrees和Composer来实现，对吗？

如果我没有用于在子文件夹上游提交/推送代码的用例，但只希望将最新/特定版本拖入子文件夹，Subtree和Composer提供的是同一种类的效用？

在我的使用案例中，我觉得Composer胜过Git Subtree更容易使用，更容易在子文件夹中获得另一个/更新版本的脚本，而无需将这些拉动的子文件夹文件提交到Git repo 。

关于这种认识的任何想法？这种策略有没有问题？或者两者完全不同，没有任何相似之处？

来源

2014-01-08 Sawant

我只是简单地将它表达为：git子树与使用git作为版本控制系统绑定在一起。你不能只迁移其他地方的文件，你总是需要将整个项目作为一个git存储库，并且你恰好使用它的次要特性来进行第三方依赖管理。另一方面，Composer是专门用于管理第三方依赖项的工具，独立于任何其他系统。我的选择似乎很清楚，但最终真的取决于你。 – deceze

即使您需要编辑依赖项中的代码，您也可以将它作为源代码“composer更新某个依赖项--prefer-source”来完成。然后，您可以同时编辑项目和依赖项的代码，并将git单独提交给它们各自的回购。 – Danack

许多理由支持作曲家。

它实际上是管理整个项目和供应商库本身的依赖项。所以如果你需要一个包，它会得到所有需要的东西或通知你有关错误。

管理版本也是微不足道的，为每次下载，你可以指定版本，应该升级到包（这样你就可以决定只更新包的次要版本或去全了与DEV-主）

作曲家也为自动加载提供了一些帮助。使用-o

运行时使您的项目更快一点通过开发唯一的软件包，您还可以使用管理生产设置更轻松。

如果供应商提供作曲家功能，我觉得没有理由使用子模块。

来源

2014-01-08 10:20:36 Uriziel

Git子树和作曲家

回答

相关问题