就方便部署和版本控制而言,组织 SPA 项目结构的正确方法是什么?

What is right way to organize structure of SPA project with respect of convenient deploy and version control?

先决条件:


我需要组织单页应用程序(SPA)项目开发,前端应该基于流行的前端js框架之一,这意味着使用基于gulp/webpack的前端构建系统来构建最终的bundle比方说 Es2015 js 来源,Sass 样式和 Jade 标记。后端应基于 Laravel 5.x.

所以我终于有了前端包,它应该可以与后端代码一起使用。在每个开发阶段,我都有特定的前端包和特定的后端代码,它们可以正确地协同工作。

问题:


  1. 如何最正确地将我的所有源代码置于版本控制之下(假设使用 Git)?我是否需要为后端和前端部分的两个单独存储库的所有项目创建一个存储库?为什么?

  2. 如何组织版本控制以最方便、最简单地将项目的当前发布版本部署到生产服务器?

这是我的想法:在一个存储库中同时拥有前端包和后端代码+迁移的实际版本看起来是个好主意,但我的困境是:对于生产我只需要前端包而不需要初始前端源代码(sass、jade 等文件)。我的前端包在前端源 code/styles/makrup 的每次更改中不断与我的构建系统一起重建,因此每次构建后输出包都是不同的。

我希望这篇文章写得很清楚,可以理解我的意思,我会询问一些可以为我澄清这些问题的文档的任何建议或链接。

If I would create two separate repos for frontend and backend, then how would I synchronize actual frontend bundle and actual version of backend code and how would I return to specific version of my project?

这通常是通过父仓库完成的,其任务是记录 frontendbackend 声明为 submodules[=34= 的正确版本].

每次 frontendbackend 更改时,您的父回购 git status 提到这些回购的 SHA1 已更改(即它们的 gitlinks, special entries in the index主要父仓库)

通过推送该父仓库(除了推送 frontendbackend 仓库),您可以跟踪哪个版本的 frontend 与哪个版本的 backend,你可以 return 到项目的特定版本(通过父 repo 历史记录)。