在方便的部署和版本控制方面，组织SPA项目结构的正确方法是什么？

Question

先决条件：

我需要对单页面应用程序（SPA）项目开发进行编程，前端应该基于一个popuplar前端js框架，这意味着使用基于gulp / webpack的前端构建系统来构建最终的捆绑包让我们说Es2015 js来源，Sass风格和Jade标记。后端应基于Laravel 5.x。

所以最后我总结了一个应该使用后端代码的bundle。在每个开发阶段，我都有一些前端捆绑和某些后端代码可以正常协同工作。

问题：

1. 如何正确地将我的所有源代码置于版本控制之下（假设使用Git）？我是否需要为后端和前端部分的两个独立回购的所有项目创建一个回购？为什么呢？

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

这是我的想法：在一个仓库中拥有前端捆绑和后端代码+迁移的实际版本似乎是一个好主意，但我的困境是：对于生产我只需要前端捆绑但不是最初的前端源代码（sass，jade等文件）。在前端源代码/ styles / makrup的每次更改中，我的前端捆绑不断地与我的构建系统重新绑定，因此每次构建后输出包都不同。

• 如果我要为后端和前端创建通用仓库，那么前端源也将包含在仓库中，我在生产服务器上不需要它们。
• 如果我要为前端和后端创建两个单独的存储库，那么我将如何同步实际的前端包和后端代码的实际版本以及如何返回到我的项目的特定版本？

我希望能够清楚地了解这一点并理解我，并且我会向某些文件提出任何建议或链接，以便为我澄清这些问题。

Answer 1

  

如果我要为frontend和backend创建两个单独的存储库，那么我将如何同步实际的frontend包和实际版本的backend代码以及如何返回到我项目的特定版本？

通常通过父代仓库完成，其任务是记录声明为 submodules 的frontend和backend的正确版本。

每次frontend和backend更改时，您的父级回复git status都会提到这些回购的SHA1已更改（即 gitlinks ，主要父回购的special entries in the index

通过推送该父级回购（除了推送frontend和backend回购），您可以跟踪frontend的哪个版本与哪个版本的backend一致，并且您可以返回到项目的特定版本（通过父回购历史记录）。