Question

我们目前正在使用SVN对软件和硬件模块进行版本控制，这些模块共同构成一个产品。为此，我们提出了以下结构（最小例子）：

modules/
   |
   |- PCB Design
   |    |- tags
   |    |   |- 0.1
   |    |   |- 0.2
   |    |   \- 0.3
   |    |- branches
   |    \- trunk
   |- VHDL
   |    |- tags
   |    |   |- 0.1
   |    |   |- 0.2
   |    |   \- 0.3
   |    |- branches
   |    \- trunk
   \- Firmware
        |- tags
        |   |- 0.1
        |   |- 0.2
        |   \- 0.3
        |- branches
        \- trunk

products/
   |
   |- Variant A
   |    |- V1
   |    \- V2
   |
   \- Variant B
        |- V1
        |- V2
        \- V3

这个想法是，例如“变体A / V2”是指不同模块的版本集合（例如，PCB v0.3，VHDL v0.2和固件v0.3）。使用svn，因为所有（标签，分支）都是一个目录，这可以通过使用subversion的浅拷贝行为来实现：

svn cp modules/PCB Design/0.3 products/Variant A/V2
svn cp modules/VHDL/0.2 products/Variant A/V2
svn cp modules/Firmware/0.3 products/Variant A/V2

实际开发绝不会在“产品”中发生，只能在“模块”中进行。

然而，这种工作方式非常面向SVN，我们正在寻找类似git的东西。我检查了子模块，但发现大多数警告不使用它们，以及子树，它们不适合这个问题。

Git还有其他可以复制类似内容的方法吗？

Answer 1

在您的特定情况下，我会假设存储在PCB / VHDL /固件中的更改完全相互独立，而且在这些存储库中工作的人员组也是唯一的？

如果是这样的话我会猜测子模块对你来说几乎不会像通常那样糟糕（此外，多年来子模块支持已经变得更好了，所以根据你读到的内容，它可能指的是更老的实施，这无疑是可怜的。）

你的ASIC人员只是在他们的VHDL回购中作为单个回购工作，他们根本不需要了解子模块。

与直接在PCB回购中进行PCB布局的EE相同。

您的软件工程师将在固件仓库中开展工作。

您只需要一个超级项目（其中包含所有这些子模块）来实际将版本标记为这3个模块的集合，并且只有项目经理需要使用它。

管理由git中的几个模块组成的产品版本

1 个答案: