您如何在源代码管理中存储第三方库? [英] How do you store third party libraries in your source control?

问题描述

您如何在源代码管理中存储您在项目中使用的第三方库?

How do you store third party libraries that you use in your project in your source control?

您什么时候将二进制文件存储在源代码管理中?

When would you store binaries in your source control?

您什么时候将代码存储在源代码管理中?

When would you store the code in your source control?

你会同时存储两者吗?在什么情况下你会这样做?

Would you ever store both? In what situations would you do this?

(顺便说一句，我使用的是 .NET，但对于这个问题并不重要)

(Btw, I'm using .NET but it doesn't really matter for this question)

推荐答案

• 方法:供应商分支 通常是一个好方法

  • How: a vendor branch is generally a good approach

    何时(第三方):为了尽量减少所涉及的引用数量:您可以将这些库添加到单独的外部引用(如 Maven)中，但这意味着您需要访问额外的每个环境的参考(开发 - 集成 - 认证 - 试生产 - 生产)

    When (thirdparties): for minimizing the number of referential involved: you could add those libraries into a separate external referential (like Maven), but that mean you need to access that extra referential for each of your environment (development - integration - homologation - preproduction - production)

    何时(代码):用于管理更改的复杂性，当您知道将需要更新和修复运行到生产环境的当前版本时正在开发中.

    When (code): for managing the complexity of the changes, when you know updates and fixes for current versions running into production will be needed while new development are in progress.

    为什么(同时存储):对于部署 原因:你可以在一个引用中管理一个完整的配置(你需要的元素列表)并查询它随时随地:

    Why (store both): for deployment reason: you can manage a complete configuration (list of elements you need) in one referential and query it wherever and whenever you need for:

    • 开发(您查询开发和执行代码所需的内容，包括编译/执行所需的第三方)
    • 测试(集成、认证):您查询要用于更新测试工作区的确切标签
    • 生产:您可以准确地确定从一个来源(您的 SCM)投入生产的内容.

    对于测试和生产环境，这也意味着您自己的产品(您正在构建的产品的打包结果)也应该进入您的 SCM(只有官方版本，而不是内部使用的中间版本)).
    如果其他项目依赖于您的产品，他们将根据您存储在 SCM 中的打包版本构建自己的项目，而不是根据他们以某种方式重新编译的源代码.

    For test and production environments, that also mean your own product (the packaged result of what you are building) should also go into your SCM (only the official releases, not the intermediate ones used internally).
    If other projects depend on your product, they will build their own project against your packaged version stored in the SCM, not against your source code they somehow recompiled.

    为什么这很重要?
    因为最终，将在生产中运行的是您产品的打包版本，而不是您的重新编译的源代码".因此，使用产品的目标最终形式进行所有测试非常重要，并在 SCM 中清楚地存储和标记.

    Why this is important ?
    Because in the end, what will run in production is that packaged version of your product, not your "source code re-compiled". Hence the importance to make all your test with the target final form of your product, clearly stored and tagged in your SCM.

    Martin Lazar 在 他的回答

    源代码控制被称为源"控制，因为它应该控制源.

    Source control is called "source" control, because it is supposed to control sources.

    虽然这在历史上可能是正确的，但每个当前的 RCS 都朝着 SCM 发展(源代码管理)，它不仅控制源，还管理文档、程序和其他存储为计算机文件的信息的更改.
    然后可以存储二进制文件(甚至可以用二进制增量存储)

    While that may have been historically true, every current RCS have evolved toward SCM (Source Code Management), which does not just control sources, but also manages changes to documents, programs, and other information stored as computer files.
    Binaries can then been stored (even stored with binary-delta)

    加上允许其中一些 SCM 提出 S"C"M 功能(如 源配置管理).
    该 SCM(配置)不仅存储任何类型的文件集"，还存储这些集之间的关系(又名依赖项)，以便您查询一个文件集，并拉取"该文件集所依赖的所有其他交付(构建、部署或运行​​)

    Plus that allows some of those SCM to propose S"C"M feature (as in Source Configuration Management).
    That SCM (Configuration) not only stores any kind of "set of files", but also their relationships (aka dependencies) between those sets, in order for you to query one set of file, and to "pull" every other deliveries on which that set depends on (to build or to deploy or to run)

    这篇关于您如何在源代码管理中存储第三方库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！