部署Angular应用时是否需为源码和ng build生成的dist产物分设两个仓库？

这种把Angular源码和ng build生成的dist产物分开存两个独立Git仓库的做法，算不上通用的最佳实践，只有少数特定场景下才适合用，具体分析如下：

适用场景 #

只有当你们团队的部署流程完全依赖拉取Git仓内容完成，没有配套CI/CD流水线，而且部署权限和源码权限需要完全隔离、部署人员不能接触源码的时候，用这种方式才比较划算，确实能省掉部署环节的构建步骤，加快发布速度。

不推荐作为通用方案的核心原因 #

• 产物无版本管理必要性：dist是源码编译生成的可复现产物，只要依赖锁文件、构建参数不变，每次执行ng build得到的内容完全一致，单独存仓属于冗余存储，还极易出现源码和产物版本不匹配的问题。
• 额外提升维护成本：每次发版要走两次提交推送流程（源码提交+产物提交），如果存在多环境部署需要对应多套产物仓的情况，版本对齐的工作量会成倍增加。
• 不符合标准DevOps规范：行业通用最佳实践是把源码仓作为唯一可信源，通过CI/CD流水线自动完成构建、产物归档、部署全流程，产物一般归档到专用制品库（比如私有Nexus、云对象存储桶等），不需要人工维护单独的产物Git仓。

必须使用分仓方案的注意事项 #

如果受限于现有基建只能沿用这套方案，建议做好以下约束：

• 每次向dist仓提交产物时，commit信息必须关联对应源码仓的commit哈希，方便后续问题排查时溯源版本。
• 可以在源码仓中配置git钩子或npm脚本，自动完成构建、产物提交、推送dist仓的全流程，降低人工操作出错概率。
• 禁止直接在dist仓中修改任何代码，所有变更必须走源码仓修改、重新构建推送的流程。

内容的提问来源于stack exchange，提问作者Noble Eugene