对于像我这样的项目，有什么可能的GIT存储库结构设计？

Question

我要把一个项目从SVN移到GIT。

该项目使用一组SQL过程。多个客户端都有自己的文件版本，但它们也使用对所有客户端相同的核心过程集。

目前，我们在SVN上拥有的是一个包含核心文件夹的文件夹和多个包含客户端特定过程的文件夹(请参阅下面的“当前文件夹结构”)。

我最初的想法是创建一个存储库，其中包含核心文件和包含每个客户端附加文件的独立分支，但后来我意识到，如果有人将文件推送到错误的分支，它可能非常危险，而且很容易变得混乱。

因此，我的另一个想法是将每个客户端的过程放在自己的存储库中，并将核心存储库作为每个存储库中的子模块进行链接。

问题：

1. 可能的存储库结构设计(工作流)是什么？我能用在这个场景上吗？
2. 他们与其他人相比有什么优点和缺点？

以下是一些可以使我的当前情况更容易理解的附加信息：

规则：

• 每个客户端的核心始终是相同的。
• 客户端文件夹包含它们自己的附加/定制文件/过程。
• 只有我的团队正在对存储库进行更改(即客户端没有访问代码的权限)。
• 可以很容易地将更改从一个clinet拉到另一个，这是有用的，但这是而不是的要求。

当前在客户端站点的部署过程：

1. 克隆包含所有核心文件+客户端所有文件的SVN存储库(请参阅下面的文件夹结构)
2. “安装”所有核心程序
3. “安装”所有客户定制的程序

项目的当前文件夹结构：

├── core
│   ├── proc-core-bar.sql
│   ├── proc-core-csv.sql
│   ├── proc-core-db.sql
│   └── proc-core-foo.sql
├── client-1
│   ├── proc-client-addr.sql
│   ├── proc-client-msgs.sql
│   └── proc-client-ordr.sql
├── client-2
│   ├── proc-client-addr-additional.sql
│   ├── proc-client-addr.sql
│   ├── proc-client-msgs.sql
│   └── proc-client-ordr.sql
├── client-3
│   ├── proc-client-addr-additional.sql
│   ├── proc-client-addr.sql
│   ├── proc-client-msgs.sql
│   └── proc-client-ordr.sql
├── client-4
│   ├── proc-client-addr.sql
│   ├── proc-client-msgs.sql
│   ├── proc-client-ordr-additional.sql
│   └── proc-client-ordr.sql
└── client-5
    ├── proc-client-addr.sql
    ├── proc-client-msgs.sql
    └── proc-client-ordr.sql 

Answer 1

可能的存储库结构设计(工作流)是什么？我能用在这个场景上吗？

• Git子模
• Git子树
• Git奴隶
• 位
• 不相关的独立repos、仅由部署工具收集和组合的数据

他们与其他人相比有什么优点和缺点？

Git子模

专业：

• 模块化回购

Contra：

• 被锁定到外部回购的特定版本。
• 缺乏有效的合并管理
• Git存储库本身并不真正知道它现在是一个多模块存储库的一般概念
• 大工作流更改

Git子树

专业：

• 模块化回购
• 减少对工作流的更改
• 子树源文件存储在回购文件中。

Contra：

• 对工作流的更改

Git从

专业：

• 除了超级项目中的一个新文件之外，对.gitignore的调整以及一些私有配置变量都不会影响您的存储库。

Contra：

位

专业：

• 处理跨不同项目和粒度组件级别的源代码和依赖关系。

Contra：

• 需要Node.js