具有多个版本的版本控制

Question

我有一般的版本控制问题。我最近写了一个应用程序，并计划在我目前的工作基础上增加新功能  我的目的是以两个不同的应用程序("my application", and "my application plus")结束，这两个应用程序都基于相同的核心代码，但其中一个版本具有内置的更多功能。
我的问题是，有没有办法让版本控制设置有两个不同的存储库（我想），但其中一个存储库引用另一个。
所以基本上如果我改变一个应用程序中的一个核心元素，它将在两者中改变它。

分支可能就是答案，但我一直认为分支用于一些代码的部分，目的是在以后合并它而不会破坏或破坏构建。我的情况有点不同。

有什么想法吗？

Answer 1

是的，你可以。

我在最近的项目中使用了以下策略，该项目在其高峰期有大约5个并发开发人员，并且运行良好。我们的案例中的base代码是核心专有产品，plus是客户端对base代码的自定义。

我们有base这样的项目空间;

repo/
- base/
 + trunk
 + branches
 + tags

我们在同一个存储库中为plus创建了项目空间;

repo/
-base/
 + branches
 + tags
 + trunk

-plus/
 + branches
 + tags
 [new trunk will go here]

使用svn copy将base/trunk克隆到plus/trunk。

base和plus现在共享一个共同的祖先。通过定期将plus合并到base/trunk，plus/trunk会保持最新状态。按照惯例，我们从未合并过加回基地。

最难的部分（我发现）是确保开发人员在提交时保持纪律。如果您开始将base代码应该plus提交到branch并稍后将其移回视图，那么很容易陷入混乱。合并通常很直接。

为了记录，我不会再在svn中这样做，我会使用git。我用svn术语描述它只是因为我以前做过。

顺便提一下，{{1}}可以用于几个不同的目的 - 功能分支，热修复，发布集成，供应商分支......所有分支，但按照惯例，它们意味着不同的东西。我所描述的仍然是一种分支 - 只是一种不按照惯例与其原始主干重新融合的分支。阿卡一个叉子。

Answer 2

通常，您将使用一个有助于分支的系统（如git）并保留单独的分支（例如：master，master-plus）。每个版本，您都会git rebase（或git merge）从您的基本应用更改为加号版本。

PS：您可以使用某种插件方法和两个repos

来做同样的事情

Answer 3

如果您的基本应用程序已经编写并且您打算实现它的扩展版本，我建议您考虑子模块，这是Git的一个功能（请在此处查看：http://git-scm.com/book/en/Git-Tools-Submodules）。它可能是整个应用程序的好解决方案，也可能只是它的核心。考虑使用它。