我想就这个想法获得一些反馈，因为我可以看到每种方法的优缺点。 作为 Java 开发人员，这将是关于将 jar 文件存储在代码存储库中，但它可以轻松扩展到其他编译语言。
优点：
缺点：
【问题讨论】：
标签： version-control
我们将发布存档到目录结构，并在源代码控制中标记适当的版本。这使我们能够访问构建的版本和生成它们的源代码。
这很容易使用构建脚本自动标记和归档发布构建。
【讨论】：
妥协：将工具和源代码存储在存储库和标记构建中。这样您就可以随时重新创建产品的任何版本。
而且您始终可以为已编译的工件提供单独的存储库。
【讨论】：
如果您可以创建一个足够好的构建系统，只需签出代码就可以轻松地重新创建一个精确的构建，我认为没有必要将您的构建存储在存储库中。
对于我的大部分内容，我不存储我的代码的特定版本，但我确实存储了我的代码所依赖的库的特定版本。几个月前，我付出了很多努力，使加载标签和输入“ant”变得微不足道，并且一切都可以正确构建，而不依赖于树之外的任何东西。 （不包括正确的 javac 和 ant）
不幸的是，我们的一些代码库没有那么好的构建系统（即，需要手动设置 sdks 并获取各种外部库和探查环境变量），并且很难准确地重新创建特定版本的构建基于存储库（我们一直在向前发展，并不真正支持旧代码，因此开发人员的工作站设置得足够近，以至于我们还没有因为必须回到当前版本之前的旧分支而被烧毁）和在这种情况下，我们确实存储了我们发布的版本（对于不可避免的胖手指“哦，不，我在错误的服务器上做一些测试”或同样阴险的东西）。
【讨论】：
我将构建存储在服务器的一个文件夹中，并定期备份它们。但是我标记了代表该构建的修订。在构建文件夹中，我不仅存储了可执行文件、二进制文件或页面（我们的案例是 ASP.Net），还存储了我们从 SQL Delta 获得的更改脚本。
标签使用与字段相同的标识符命名，因此如果您有构建“System_2009-07-30-01”，您将拥有一个具有该名称的标签。因此，如果您需要修复某些问题，您只需查看构建名称、查看标签，然后查看您需要的修订版本，看看会发生什么。
【讨论】：
我认为没有充分的理由对实际构建进行版本控制。标记源版本并使其只有受控组有权更改标记。构建标签不应该对其进行签入，因此重新创建构建应该是微不足道的。
【讨论】：
我们会为任何构建标记存储库，这样我们就可以获得任何构建号的实际来源，然后我们压缩并上传实际部署的实际发布的构建文件 - 只是为了确保没有偷偷摸摸的最后一分钟配置调整部署期间的等，这些都不会反映在主干本身中。
【讨论】：
我认为将构建输出存储在版本控制系统中是合适的。既可以测试某个特定版本的构建，也可以简化某些开发任务。
但是，您应该确保将所有内容保存在存储库中，以便在需要时重新创建确切的构建。您应该使用一致的标记/标签来促进这一点。您可能需要使用各种组件的不同版本来测试错误修复，并且根据整个系统的复杂性，您可能需要尝试不同的组合。
【讨论】：
有时。大多数情况下，答案是否，但仍有一些场景，如果它有意义，就去做。
顺便说一句，我很惊讶这仍然是开放的。这些讨论类型的问题通常会在 5 分钟内投票结束。
【讨论】：
为了减轻对旧构建工具可能无法在新环境中运行的担忧，我们将构建机器映像存档以供主要版本使用。这对我们来说很容易，因为我们的构建机器是虚拟化的。如果其他方法不起作用，这是B计划。
【讨论】：
将特定的客户版本放入存储库中。
从理论上讲，这不是必需的，因为我们总是可以重现该版本，但能够获得在特定日期发送给特定客户的确切 .msi 非常好 - 然后我们在干净的 vm 中对其进行测试。
一个原因是它可以保护您免受构建环境之外的任何更改，例如 Windows 或 Visual Studio 更新。如果 msi 本身已更新，您可能无法重现 msi 的位构建！
【讨论】：
我认为源代码、依赖项、二进制文件和构建工具应该一起进行版本控制...这是跟踪最终发布来自许多源项目的大型项目的唯一方法...
【讨论】：