在我工作的地方，我们需要重新思考我们开发软件的方式并跟踪每个发布的版本。您有什么建议可以解决我们的问题吗？
我们使用VS 2005在C ++上开发（以及用于某些界面的C ++ Builder）
我们使用GIT，但可能的方式更糟糕。我们有点愿意转向另一个源代码控制。
我们有40多个内部开发的DLL。其中许多可以经常更新。
我们有一些显着不同的项目依赖于这些DLL。
我们每年提供100多个系统，每个系统都需要自定义配置。大多数还需要自定义补丁。我们尽可能地尝试将这些补丁带回主干，但叉子是不可避免的。
如果几年后我们必须更新客户端的系统，我们应该能够找回用于该版本的代码和所有环境参数。我们需要一种方法来验证此代码是否与客户端系统上的二进制文件匹配。获取代码应该尽可能简单，除了编译器之外，我们应该通过一些简单的操作来完成编译所需的一切。
程序员应该能够在不依赖任何其他程序员的情况下发布客户端系统的更新，无论补丁是什么项目（DLL）。他应该能够快速完成（不到30分钟）。这使得单一正式发布的概念几乎不可能。
在处理同一项目的开发人员之间交换代码应该简单快捷。
考虑到我们庞大的代码库，我们希望限制开发人员在获得补丁时重新编译的程度（共享二进制文件是必须的）。
开发人员应该能够轻松地从一个客户端的系统版本或分支机构切换到另一个客户端（通常需要同时处理多个版本）。
编辑： - 到目前为止我们还没有使用makefile，但这是我们愿意考虑的事情。一切都是使用VS解决方案构建的。
答案 0 :(得分：3)
Git本身非常适合拥有众多源代码分支。但是，这些分支的维护将始终驻留在用户处，并且不在给定版本控制系统的范围之内。
Git的唯一问题是，随着时间的推移，它无法很好地跟踪编译的二进制数据。二进制数据主要是一次性使用，而对源代码很重要的diff / patch方面对于编译的二进制数据并不重要。相反，只需为Git中的每个源代码版本创建一个.zip文件，其中包含每个DLL的预编译版本，并将这些.zip文件放在网络共享上。
如果你已经这样做了，听起来你应该花时间进入构建系统以提高效率。版本系统可以在这里提供帮助，但无论如何你可能会遇到构建问题：
最后，我们推出了我们自己的构建系统，该系统的速度有限，在没有任何更改的情况下对所涉及的所有文件执行stat（）。但是，这需要一些时间来构建。构建自己的系统时需要考虑的事项：
好的是，这是所有版本控制系统独立的，所以不浪费时间。它甚至可能是一个简单的近似就足以能够做到<30分钟。这取决于。