我有一个一般的版本控制问题。我最近编写了一个应用程序，并计划在我当前工作的基础上添加新功能。
我的意图是以两个不同的应用程序结束("my application", and "my application plus")，它们都基于相同的核心代码，但其中一个版本具有更多内置功能。
我的问题是，有没有办法让版本控制设置具有两个不同的存储库（我假设）但其中一个存储库引用了另一个。
所以基本上，如果我在一个应用程序中更改其中一个核心元素，它将同时更改它。
分支可能是答案，但我一直认为分支是用来分割一些代码的，目的是稍后将其合并回来，而不会中断或破坏构建。我的情况有点不同。
有任何想法吗？
是的你可以。
我在最近的一个项目中使用了以下策略，该项目在高峰期有大约 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. 按照惯例，我们从未从 plus 合并回 base。
最困难的部分（我发现）是确保开发人员在提交时保持自律。如果您开始将应该编写的base代码提交到plus视图中以便稍后将其移植回来，那么很容易陷入混乱。合并通常非常简单。
为了记录，我不会再在 svn 中这样做，我会使用 git。我用 svn 术语描述它只是因为我以前做过。
顺便说一句，abranch可以用于多种不同的目的——特性分支、热修复、发布集成、供应商分支……所有分支，但按照惯例，它们的含义不同。我所描述的在某种程度上仍然是一个分支——只是一个没有按照惯例重新整合到其原始主干的分支。又名叉子。
通常，您会使用有助于分支的系统（例如git）并保留单独的分支（例如：master、master-plus）。每个版本，您都会git rebase（或git merge）从基本应用程序更改为 plus 版本。
PS：你也可以用某种插件方法和两个 repos 做同样的事情
如果您的基础应用程序已经编写好并且您打算实现它的扩展版本，我建议您考虑作为 Git 功能的子模块（在此处查看：http: //git-scm.com/book/en/Git -工具-子模块）。它可能是整个应用程序或仅适用于其核心的良好解决方案。考虑使用它。