Flutter项目是否需要为每个发布版本单独创建代码仓库？

这个做法和微服务架构没有任何关联，不属于任何公认的前端/Flutter工程化实践，本质是缺乏版本管理能力的临时凑数操作。

微服务（包括前端侧的微前端拆分）的多仓库实践，核心是把具备独立业务边界、可独立迭代部署的模块拆分为独立代码仓，每个仓库存放对应模块的源码、构建配置、完整版本记录，从来没有“每个演示版本单独建仓、仅存单次提交的Web编译产物”的相关规范，原开发者给客户的说法属于托词。

• 原开发者没有对Flutter项目做正规的源码版本管理，甚至本地都没有维护规范的Git提交记录，每次给客户出演示包前临时编译Web产物，怕后续修改覆盖之前可运行的演示版本，就随手新建仓库把编译后的静态文件夹丢进去存底，单次提交就是传完产物就不再维护这个仓
• 所有仓库仅存构建产物的特征，基本可以判定你拿到的这些仓里没有可二次开发的Flutter源码，只有编译后混淆过的Web静态资源，原开发者很可能没有交付完整源码的打算，或者本地源码已经遗失
• 选择这种零散存包的方式，大概率是团队没有搭建私有制品库、静态文件托管服务，拿Git仓库凑数当版本归档的存储介质，完全属于运维层面的临时 workaround，和架构选型没有关系

只有一种极特殊场景下该操作具备临时合理性：客户强制要求所有历史演示版本必须独立留存、不可修改覆盖，且项目团队完全没有条件搭建专门的制品存储服务，才会临时用Git仓库存放静态构建产物做版本留档。但即便在这种场景下，该操作也和“优先采用微服务架构”的说法完全无关。

• 第一时间排查原开发者的工作设备、云同步盘、协作平台记录，优先找回包含lib/目录、pubspec.yaml文件的Flutter源码，你目前拿到的所有仓库都是编译后的静态产物，无法直接支撑后续迭代开发
• 抽样解压不同仓库的构建产物，检查硬编码的后端接口地址、静态资源版本特征，确认是否存在真的拆分了独立前端模块的极小概率情况：如果所有版本对接的是同一套后端、页面功能是连续迭代的关系，可以彻底排除微服务/微前端拆分的可能
• 接手后无需保留现有零散的单提交仓库结构，把所有历史构建产物按版本号归档到同一个仓库的发布目录下，用Git tag标记每个演示版本即可；后续源码迭代走正规的单仓/多模块分支管理流程，编译产物统一走制品库存档，不要直接把构建产物提交到源码仓。

内容的提问来源于stack exchange，提问作者Charl van Staden