版本控制与多个版本

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

分支可能是答案，但我总是认为分支被用于部分代码的一部分，意图在稍后将其合并回来而不会中断或破坏构建。我的情况有点不同。

任何想法？

来源

2013-04-27 BarryBostwick

我建议分离版本和变体，即实现具有不同（构建）配置的变体 - 而不是使用不同的软件模块。 – nosid 2013-04-27 21:01:40

正确或者在核心库中具有核心功能，并且在与核心库链接的独立回购库中具有附加组件。 – tripleee 2013-04-27 21:14:46

-1

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

PS：你可以ALO做同样的某种插件的方法和两个回购

来源

2013-04-27 21:17:04

-1

如果您的基本应用已经写好，你打算实施它的扩展版本，我建议你去思考的子模块，其是Git的一个特性（在这里查看：http://git-scm.com/book/en/Git-Tools-Submodules）。这可能是整个应用程序的良好解决方案，也可能只是其核心。考虑使用它。

来源

2013-04-27 21:38:48 tkestowicz

是的，你可以。

我在最近的一个项目中使用了以下策略，该项目在高峰时期有大约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而保持最新。按照惯例，我们从来没有从加回合基地。

Fork Strategy

（我发现）是确保开发者提交时保持纪律最难的部分。如果您开始将base代码转入plus以便稍后将其返回，则很容易造成混乱。合并通常非常简单。

为了记录我不会再次在svn中做这个，我会使用git。我之所以用svn来描述它，仅仅是因为我以前做过。

顺便提一句，branch可用于几个不同的目的 - 功能分支，热修复，发布集成，供应商分支......所有分支，但按照惯例，它们意味着不同的事情。我所描述的仍然是某种方式的分支 - 只是一种不按照惯例重新整合其原始主干的方式。又名叉子。

来源

2013-04-28 13:36:02 mounds

版本控制与多个版本

回答

相关问题