Question

我们有一个自定义项目“kickstart”

这个kickstart可以很容易地添加模块。

当我们构建这些模块时，我们基于一个版本控制的kickstart的干净主副本来构建它们。

当我们开始一个项目时，我们创建一个空的回购，将kickstart repo设置为遥控器，从遥控器拉。当核心更新时，我们再次从遥控器上拉。

这很有效。

但是我们有我提到的模块，我们在干净的kickstart上构建它们作为一个新项目。

我们希望版本控制所有这些模块。

模块的文件实际上位于模板内。

我们的工作流程看起来像这样

/site 1
  /kickstart
    /module1
      /module1 files
    /module2
      /module2 files
  /site 1 specific file
  /site 1 specific file

/site2
  /kickstart
    /modification of kickstart file for site2 only (e.g. config.php)
    /module2
      /module2 files
    /module3
      /module3 files
  /site 2 specific file
  /site 2 specific file

/site3
  /kickstart
    /modification of kickstart file for site3 only (e.g. config.php)
    /module1
      /module1 files
    /module3
      /module3 files
  /site 3 specific file
  /site 3 specific file

所以，站点1,2和3是他们自己的git存储库。

它们都包含kickstart，这是一个git存储库

其中一些人共享模块。

现在我们不会从这些上游推进，如果我们在网站1中做了一些有效的工作，我们将检查kickstart的干净副本并在那里进行更改，然后将它们拉到所有不同的站点。模块也一样。

但我的基本问题是，我们把模块放在哪里？他们依赖于那里的kickstart。

一个想法是将它们作为kickstart的分支，我也听说过子模块和子树，但不知道它们是如何工作的。

构建此工作流程的最佳方法是什么？

Answer 1

将这三个站点放在他们自己的Git仓库中（而不是使用一个带有三个分支的仓库），意味着您不必在site1,2和3之间进行太多（如果有的话）合并：所有3个只有一个remote：kickstart repo。

关于模块管理，每个模块都应该在自己的repo中，以便轻松使用子模块或子树：

子模块是一种将每个模块及其完整历史记录单独放在其自己的目录中的方法，甚至可以回送到每个模块库。
子树有两种形式：2007 subtree merge strategy（解释here）和recent (1.7.11+) subtree command。
subtree merge strategy（参见also here）我更适合将其中一个模块repo合并到一个子目录（modulex）中。由于您不需要退回，因此可能是您的解决方案。

子项目的Git工作流程？

1 个答案: