2014-01-08 137 views
1

這可能是一個很天真的問題,但我想了解Git的Subtree和Composer依賴管理PHP之間的效用差異。在轉儲Git子模塊後,我開始使用Git子樹。但現在有Composer(用於PHP)。由於我的大部分項目都是基於PHP的,我正在考慮傾銷Subtrees轉而使用Composer。Git子樹和作曲家

例如,我有多個Wordpress網站。我想拉動Wordpress本身和我想要使用的插件。我可以通過Git Subtrees和Composer來實現,對嗎?

如果我沒有用於在子文件夾上游提交/推送代碼的用例,但只希望將最新/特定版本拖入子文件夾,Subtree和Composer提供的是同一種類的效用?

在我的使用案例中,我覺得Composer勝過Git Subtree更容易使用,更容易在子文件夾中獲得另一個/更新版本的腳本,而無需將這些拉動的子文件夾文件提交到Git repo 。

關於這種認識的任何想法?這種策略有沒有問題?或者兩者完全不同,沒有任何相似之處?

+1

我只是簡單地將它表達爲:git子樹與使用git作爲版本控制系統綁定在一起。你不能只遷移其他地方的文件,你總是需要將整個項目作爲一個git存儲庫,並且你恰好使用它的次要特性來進行第三方依賴管理。另一方面,Composer是專門用於管理第三方依賴項的工具,獨立於任何其他系統。我的選擇似乎很清楚,但最終真的取決於你。 – deceze

+1

即使您需要編輯依賴項中的代碼,您也可以將它作爲源代碼「composer更新某個依賴項--prefer-source」來完成。然後,您可以同時編輯項目和依賴項的代碼,並將git單獨提交給它們各自的回購。 – Danack

回答

5

許多理由支持作曲家。

它實際上是管理整個項目和供應商庫本身的依賴項。所以如果你需要一個包,它會得到所有需要的東西或通知你有關錯誤。

管理版本也是微不足道的,爲每次下載,你可以指定版本,應該升級到包(這樣你就可以決定只更新包的次要版本或去全了與DEV-主)

作曲家也爲自動加載提供了一些幫助。使用-o

運行時使您的項目更快一點通過開發唯一的軟件包,您還可以使用管理生產設置更輕鬆。

如果供應商提供作曲家功能,我覺得沒有理由使用子模塊。