該項目的演變反映了許多軟件開發旅程：開始簡單，然後適應日益增長的複雜性。最初，它在單個存儲庫中進行了大型，整體上的應用，它通過建築重構和存儲庫管理的多個階段演變而成。
Leoloso/Pop項目始於WordPress網站，將主題和插件組合在一個存儲庫中。這提供了最初的開發便利性，但是隨著越來越多的具有類似功能的站點，很快就變得笨拙。存儲庫的成長涵蓋了大約十個站點，創造了一場維護噩夢。搜索和替換多個站點的字符串效率非常低。
為了解決可伸縮性問題，該應用程序被重構為由作曲家管理的獨立PHP軟件包。這需要轉移到多宗修置結構，每個軟件包一個存儲庫。在促進代碼可重複性和更好的體系結構的同時，管理200多個存儲庫變得非常繁重。版本控制依賴關係和跨眾多存儲庫的拉力請求是非常複雜的。缺乏集中管理系統阻礙了有效的發展。
該解決方案是一個monorepo，一個單個存儲庫託管所有軟件包。這個簡化的版本控件，允許同時發行和簡化的拉請請求。但是，由於Packagist需要單個存儲庫來發布包裝，因此採用了兩管擱置的方法：開發的MonorePo和單獨的分發存儲庫。這需要使用MonorePo Builder工具來處理MonorePo的過程。這個階段顯著提高了開發速度，尤其是在重構期間。通過自定義的GitHub操作同時發布多個WordPress插件的能力，可以進一步提高效率。
儘管具有優勢，但MonorePo仍提出了限制：在所有軟件包中執行單個許可證，管理大型發行板，即使沒有代碼更改也沒有包裝的獨立版本來處理。
管理公共代碼和私人代碼的需求導致採用了多環形體系結構。公共Monorepo（Leoloso/pop）是上游存儲庫，而私人Monorepo（Leoloso/GraphQlapi-Pro）充當下游存儲庫，將公共MonorePo納入了Git子模型。這使私人存儲庫可以訪問和擴展公共代碼庫，從而可以使用單個適用的工作流來生成公共和私人插件版本。
但是，這種方法引入了複雜性。下游存儲庫需要明確檢查子模型，需要仔細管理工作流程並可能破壞上游存儲庫的變化。這需要仔細的代碼審查和溝通，以防止意外後果。
該項目的存儲庫結構的演變突出了適應不斷變化的需求的重要性。每個階段都提供了優勢和缺點，最終導致了當前符合項目要求的多環境設置。但是，未來需求可能需要在存儲庫管理策略中進一步迭代。 “最佳”方法仍然取決於上下文，強調軟件開發和存儲庫管理的迭代性質。
以上是從單個存儲庫到多重repo，再到monorepo，再到多月園的詳細內容。更多資訊請關注PHP中文網其他相關文章！
