使用Composer時，如何處理在另一個存儲庫中擁有存儲庫？

我有一個項目，我使用Git在這個項目中進行版本控制。在這個項目中，我必須添加一些庫作爲依賴項（更具體地說PHPUnit和Guzzle）。要求說這些庫必須存在於我的項目文件夾中，我必須使用作曲者來安裝/更新它們。使用Composer時，如何處理在另一個存儲庫中擁有存儲庫？

所以我做了這一點，我的目錄結構看起來是這樣的：

project 
|----- .git 
|----- libs 
     |---- guzzle 
       |---- .git 
     |---- phpunit 
       |---- .git

所以guzzle和phpunit文件夾都有一個單獨的文件夾.git。這是因爲，據我所知，作曲家爲了檢索這些庫的源代碼而對github的主分支進行了克隆。

所以我做了一個提交+推送遠程存儲庫。但是，當其他人從該存儲庫中抽取時，libs/guzzle和libs/phunit文件夾中包含的文件不會顯示在該人員的工作目錄中。

我在想這是因爲2 .git文件夾。

我該如何解決這個問題？我嘗試搜索作曲家的文檔，以便在composer.json中指定只獲取最後一個快照的方式。但我找不到任何東西。

我也考慮刪除.git目錄，但是如果我在幾個月內嘗試做composer update，那麼這樣做會不會破壞一切？

過去有沒有人有這樣的問題？你是如何解決它的？

來源

2013-10-21 Radu Murzea

我瘋狂的猜測是submodules – Soundz

@Soundz你能更具體一點嗎？ –

作曲家（以及Maven等其他類似工具）的巨大優勢之一是您無需在代碼中包含依賴關係，作曲家可以爲需要它們的人下載依賴關係。只需將整個'libs /'文件夾放在.gitignore中，並讓人們使用composer下載依賴關係。 – 1615903

我有一些意見和解釋。

首先，您對Composer的使用創建了git clone文物。雖然這並非完全錯誤，但應該避免這種情況，因爲克隆活動項目的回購通常比安裝發佈版本的數據多得多。

如果可以，請嘗試使用--prefer-dist。這將下載該版本的ZIP文件，而不是從Github克隆。請注意，此選項是穩定版本的默認選項，這使我可以進入下一點...

請使用穩定版本。如果可以避免，請勿使用dev-master版本。你提到使用PHPUnit和Guzzle。兩者都以穩定版本發佈，您可以使用。做到這一點。這兩個庫使用不穩定的開發版本沒有好處，除非你絕對需要一個特性。使用不穩定版本的問題可能不會立即顯示。但考慮一下從現在開始半年後會發生什麼。有人更新您的依賴關係，指向dev-master，現在指向自此之後發生的任何事情。 PHPUnit或Guzzle可能會有一個新的主要版本，其中包含不兼容的更改。現在你的項目不必要地打破了。

另一件事是要求將外部庫放在定義的文件夾中。這是可行的，但它不應該完成。作曲家可以處理任何文件夾，但是我通常在頂層目錄中看到composer.json的反應是希望獲得包含autoload.php的vendor文件夾。改變這一點需要更多的解釋給一位新的開發人員，他可能也希望Composer儘可能地默認工作。因爲沒有理由將Composer管理的依賴關係放在任何地方，所以最好放在每個人都期望的地方。 如果不需要，請不要更改vendor文件夾。

最後一點是：請確認您的composer.lock，但不要提交vendor文件夾。這是因爲供應商文件夾可能包含外部庫使用的源代碼管理系統的痕跡，這些可能會混淆您的項目源代碼管理。正確的工作流程是提交composer.lock，每個簽出項目的人都必須運行composer install以從互聯網抓取這些依賴關係。這也適用於執行結帳的部署腳本。

來源

2013-10-21 18:32:14 Sven

+1優點，謝謝。我會向你的團隊介紹你的答案，我會確保我們在這裏討論一切。作曲家的確將所有內容與'autoload.php'一起放在一個** vendor **文件夾中，就像它應該一樣。這個結構並沒有出現在我的問題中，在寫這個問題時，這是我的錯誤。整個故事發生是因爲我試圖提交整個供應商文件夾。餿主意。指出。噢，關於使用穩定版本的優點。我確實這樣做了，但堅持這一點並不難，這很重要。再次感謝你。 –

顯然我想要做的是一個壞主意，如提到here。我將不得不尋找另一種安裝/使用這些庫的方式。

來源

2013-10-21 12:15:28

使用Composer時，如何處理在另一個存儲庫中擁有存儲庫？

回答

相關問題