开发代码的多个实例的版本控制答案

【问题标题】：Version control for multiple instances of a developing code开发代码的多个实例的版本控制
【发布时间】：2010-11-04 09:12:27
【问题描述】：

我在工程实验室工作，而不是计算机科学实验室。因此，我们的内部软件不是可交付的产品。相反，内部软件用于分析工程问题，并由我们提供结果。

这使得版本控制成为一个活生生的地狱。或者我应该说标准的“主干和分支”版本控制树结构似乎并不适用。我希望有人能提出更好的做事方式。

例如，每个工程项目都需要添加特定于案例的输入文件、运行时文件和后处理文件。这些都不属于trunk，因为它们不是通用的，但是每个新项目都需要这些文件。我们尝试将模板放在主干中，但没有明确的最佳实践来确定何时应该合并模板。

同样，随着我们添加新功能，内部代码也在不断发展。其中许多应该合并到主干中，以便它们可用于未来的应用程序。但是，也有很多特定于案例的 hacks 不需要看到。

我们应该如何组织这个烂摊子？显然，越简单越好。

【问题讨论】：

【解决方案1】：

我们真的努力让我们的项目保持独立：

分支用于开发工作，那些“输入文件、运行时文件和后处理文件”将按照自己的节奏发展。

对于那种文件，我们在 VCS 中管理的是：

模板
脚本能够采用该模板并生成（私有，如未版本化的）配置文件，其中包含正确的值。
这些值来自另一个引用，例如数据库，团队（或环境管理员）可以在其中随意更新它们，而不用担心签出/签入/合并。
如果需要，该数据库可以在其自己的 VCS 中进行版本控制（例如，请参阅 SO question，或者，作为替代方案，请参阅 that one）

【讨论】：

所以你会建议三个独立的树？一个源文件树、一个模板和脚本树，以及一个项目树（我猜是一组标签），其中包含源文件和配置文件的特定案例版本？
@weymouth：不，源、模板和脚本可以在同一棵树中，因为它们是链接在一起的。你有一棵树和一个数据库。对于给定的树版本，您需要一个约定来从数据库中获取正确的值。

【解决方案2】：

在工程中，版本控制经常被低估，而为了重复实验，必须恢复给定的设置。对于易于使用的一般采用，主要面向 GUI，工具有很大帮助。

利用版本控制和将问题与代码提交相关联的问题跟踪可极大地提高工作效率。

关于存储库结构，至少从颠覆来看，只有约定，没有工具强加的严格规则。如果有一个名为“主干”的树来管理所有“公共代码”呢？

对于每个工程任务，都会创建一个分支。这只不过是一个带有版本控制的“项目文件夹”。与其他项目相关的源代码将合并回主干。

【讨论】：