版本控制的开发代码

Question

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

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

例如，每个工程项目都需要添加特定于案例的输入文件，运行时文件和后处理文件。这些都不属于主干，因为它们不是一般的，但每个新项目都需要这些文件。我们试图把模板树干但有作为模板时，应合并起来没有明确的最佳实践。

同样，内部代码随着我们添加新功能而不断发展。其中很多应该合并到主干中，以便将来可以使用它们。但是，也有不少特定于案例的黑客行为，干线并不需要看到。

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

Answer 1

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

• 源文件（在你选择的任何VCS管理，像SVN）
• 配置文件（具体到一个团队或环境）

分支机构针对开发工作而那些“输入文件，运行时文件和后处理文件”将按照自己的进度发展。

对于类型的文件，我们在VCS管理的是：

• 模板
• 脚本能够采取的模板，生成（私人，如没有版本）的配置文件，它的正确值。
  值来自另一个参照，如数据库，那里的球队（或环境管理员）可以随意进行更新，没有关于结帐/签入/合并的任何问题。
  该数据库然后可以在自己的VCS如果需要的话版本（见本SO question例如，或者，作为替代，that one）

Answer 2

在工程版本控制往往被低估，而有必要恢复给出的设置以重复实验。对于易于使用的一般采用，主要是面向GUI的工具，帮助很多。

利用带问题跟踪的版本控制，将问题与代码提交相关联，极大地提高了生产力。

关于存储库结构，至少看颠覆，只有约定，但没有严格的工具规定的规则。如何管理一个名为'trunk'的树，所有'通用代码'都被管理。

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