在我工作的地方，我们需要重新思考我们开发软件的方式并跟踪每个发布的版本。您对解决我们的问题有什么建议吗？
我们使用 VS 2005(以及一些界面内容的 C++ Builder)在 Windows 上使用 C++ 进行开发
我们使用 GIT，但使用的方式是可以想象的最糟糕的。我们对转向另一个源代码控制持开放态度。
我们有 40 多个内部开发的 DLL。其中许多可以经常更新。
我们有几个截然不同的项目依赖于这些 DLL。
我们每年交付 100 多个系统，每个系统都需要自定义配置。大多数还需要定制补丁。我们尽最大努力将这些补丁带回主干，但 fork 是不可避免的。
如果几年后我们必须更新客户端的系统，我们应该能够取回用于该版本的代码和所有环境参数。我们需要一种方法来验证该代码是否与客户端系统上的二进制文件匹配。取回代码应该尽可能简单，也许除了编译器之外，我们应该通过执行一些简单的操作来获得编译所需的一切。
程序员应该能够为客户端系统发布更新，而无需依赖任何其他程序员，无论补丁位于哪个项目(DLL)中。他应该能够快速完成(不到 30 分钟)。这使得单一正式版本的概念几乎不可能实现。
从事同一项目的开发人员之间交换代码应该既简单又快捷。
考虑到我们庞大的代码库，我们希望限制开发人员在获得补丁时必须重新编译的量(必须共享二进制文件)。
开发人员应该能够轻松地从一个客户端的系统版本或分支切换到另一个版本(通常必须同时处理多个版本)。
编辑: - 到目前为止我们还没有使用 makefile，但我们愿意考虑这一点。一切都是使用 VS 解决方案构建的。
最佳答案
Git 本身非常适合拥有多个源代码分支。但是，这些分支的维护始终由用户负责，并且不在给定版本控制系统的范围内。
Git 的唯一问题是它不能很好地扩展以跟踪编译的二进制数据随时间的变化。二进制数据大多是一次性使用的，对于源代码很重要的差异/补丁方面对于编译后的二进制数据并不重要。相反，只需在 Git 中为每个源代码版本创建一个 .zip 文件，其中包含每个 DLL 的预编译版本，并将这些 .zip 文件放在网络共享上。
如果您已经这样做了，那么听起来您应该在构建系统上投入时间以提高效率。版本系统可以在这里提供帮助，但无论如何您可能会遇到构建问题:
- 您的构建系统应该仅在源代码发生更改或它所依赖的 DLL 的接口(interface)发生更改时才编译 DLL。这有多棘手取决于所使用的语言:C# DLL 有相当严格的接口(interface)，这使得这变得很容易，而 C 没有接口(interface)可言(只需在源文件中添加一个#define，所有内容都可能需要编译) )
- 您的构建系统应重用应存储在某处的预编译 DLL。最好不要与源代码相同，因为 Git 没有为此进行优化。
- 您的构建系统应该可以正常处理分支更改。例如，Visual Studio 会留下一些文件，并且并不总能正确检测何时必须完成完整重建。
- 您的构建系统可能必须使用固定位置的编译器，而不是开发人员 PC 上安装的最新编译器。您可能还希望将其置于版本控制之下，或者至少明确此依赖关系。
最后，我们推出了自己的构建系统，在没有任何更改的情况下对所有涉及的文件执行 stat() 时，速度受到限制。然而，这需要一些时间来构建。构建自己的系统时要考虑的事项:
- 首先构造一个依赖图:DLL 依赖于其源文件和其他 DLL。
- 使用文件的修改时间 (mtime) 作为文件的一种“版本”。保留这些 mtime 的缓存，并将 mtime 的更改视为更新缓存的原因。
- 当一个文件的一个mtime发生改变时，你必须重建它所属的DLL。 DLL重建后，检查接口(interface)是否发生变化。如果接口(interface)发生变化，则重建所有依赖于该接口(interface)的DLL。这需要一次图形遍历来仅处理 DLL 一次。
- 使编译并行运行的奖励。由于您知道依赖关系图，因此您还知道可以并行构建哪些 DLL。
好处是这完全独立于版本控制系统，因此不会浪费时间。甚至可能一个简单的近似就足以在 30 分钟内完成。这取决于。
关于c++ - 解决我们的版本控制和构建问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1189687/