该项目的演变反映了许多软件开发旅程：开始简单，然后适应日益增长的复杂性。最初，它在单个存储库中进行了大型，整体上的应用，它通过建筑重构和存储库管理的多个阶段演变而成。
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中文网其他相关文章！
