Git 与客户打交道时的结构
Git Structure when dealing with clients
请多多包涵。我不是 git 专家,所以我在这里所说的一切可能都是错误的。
好的。所以我看到了几个和这个类似的问题。但是,我觉得我的不同,所以在这里问一下。
我们在 Github 中创建了几个微应用程序。我觉得我把微应用之间的所有公共部分都去掉了,把它们分成了一种库,供所有微应用使用。
客户会购买我们的微应用程序,但有时希望以一种不常见的方式对其进行定制。但是,不管怎样,每个微应用中的大多数文件都不会发生变化。
我为每个微应用程序和库创建了一个存储库。我对如何构建客户的存储库有疑问。
我目前的结构如下:
MicroApp1
|-- File 1
|-- File 2
|-- File 3
MicroApp2
|-- File 1
|-- File 2
|-- File 3
MicroAppLibrary
|-- File 1
|-- File 2
|-- File 3
我的第一个问题是我应该如何将库包含在主要的微应用存储库中?根据我的理解,我应该使用子模块。我希望能够更新库存储库并将其合并到所有微应用程序存储库。
我的第二个也是更深层次的问题是我应该如何构建客户的存储库?我正在考虑的方法是为每个客户拥有一个存储库。在每个存储库中,我都会有基本上包含存储库的目录。像下面这样(如果我不做子模块,而是每次都克隆库):
Client 1
|-- MicroApp1
|-- File 1
|-- File 2
|-- File 3
|-- MicroApp2
|-- File 1
|-- File 2
|-- File 3
|-- MicroAppLibrary
|-- File 1
|-- File 2
|-- File 3
我的问题是如何更新代码并将其合并到我所有客户的存储库中?例如,如果我在微应用的主存储库中进行更改,我将如何将该更改推送到所有客户的存储库?似乎我无法将存储库合并到目录中。我会改用分支机构吗?有很多微应用程序,我也希望在每个微应用程序上都有一个 dev 和 prod 分支。
我还有很多问题,但觉得一个问题太多了 post。
- 忘记子模块,使用子树
- 如果 GitHub,则每个客户的微应用程序存储库都创建为基础微应用程序的分支,并且在其中执行所有 customer-specific 自定义,同时您始终可以从基础中提取常见更改
有一个特殊的 GitHub 应用程序,名为 Git X-Modules。与子模块不同,此工具允许您仅将存储库中的某些文件夹添加为模块,并在后台自动更新。因此,您可以为每个客户创建一个单独的存储库,向其中添加所需的组件,并设置 one-way 同步(以便将主项目存储库的更新拉到客户的存储库中,但不是虎钳反之亦然)。
请多多包涵。我不是 git 专家,所以我在这里所说的一切可能都是错误的。
好的。所以我看到了几个和这个类似的问题。但是,我觉得我的不同,所以在这里问一下。
我们在 Github 中创建了几个微应用程序。我觉得我把微应用之间的所有公共部分都去掉了,把它们分成了一种库,供所有微应用使用。
客户会购买我们的微应用程序,但有时希望以一种不常见的方式对其进行定制。但是,不管怎样,每个微应用中的大多数文件都不会发生变化。
我为每个微应用程序和库创建了一个存储库。我对如何构建客户的存储库有疑问。
我目前的结构如下:
MicroApp1
|-- File 1
|-- File 2
|-- File 3
MicroApp2
|-- File 1
|-- File 2
|-- File 3
MicroAppLibrary
|-- File 1
|-- File 2
|-- File 3
我的第一个问题是我应该如何将库包含在主要的微应用存储库中?根据我的理解,我应该使用子模块。我希望能够更新库存储库并将其合并到所有微应用程序存储库。
我的第二个也是更深层次的问题是我应该如何构建客户的存储库?我正在考虑的方法是为每个客户拥有一个存储库。在每个存储库中,我都会有基本上包含存储库的目录。像下面这样(如果我不做子模块,而是每次都克隆库):
Client 1
|-- MicroApp1
|-- File 1
|-- File 2
|-- File 3
|-- MicroApp2
|-- File 1
|-- File 2
|-- File 3
|-- MicroAppLibrary
|-- File 1
|-- File 2
|-- File 3
我的问题是如何更新代码并将其合并到我所有客户的存储库中?例如,如果我在微应用的主存储库中进行更改,我将如何将该更改推送到所有客户的存储库?似乎我无法将存储库合并到目录中。我会改用分支机构吗?有很多微应用程序,我也希望在每个微应用程序上都有一个 dev 和 prod 分支。
我还有很多问题,但觉得一个问题太多了 post。
- 忘记子模块,使用子树
- 如果 GitHub,则每个客户的微应用程序存储库都创建为基础微应用程序的分支,并且在其中执行所有 customer-specific 自定义,同时您始终可以从基础中提取常见更改
有一个特殊的 GitHub 应用程序,名为 Git X-Modules。与子模块不同,此工具允许您仅将存储库中的某些文件夹添加为模块,并在后台自动更新。因此,您可以为每个客户创建一个单独的存储库,向其中添加所需的组件,并设置 one-way 同步(以便将主项目存储库的更新拉到客户的存储库中,但不是虎钳反之亦然)。