使用存储库
当使用存储库（我想到的是 github）时，我们还应该提交第三方库吗？例如，boost 和 poco 通过示例编译为 5G。我们应该将所有这些都上传到 github 吗？如果没有，那么我们如何使库与其他人保持同步？
抱歉，缺少大小写和语法。我用手机打字，很难打字。
When working with repos (I have github in mind), should we also commit third party libraries? For example, boost and poco compile to 5G with samples. Should we upload all that to github? If not, then how do we keep the libraries in sync with other people?
Sorry about lack of capitalization and grammar. I am on my phone and it is difficult to type.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
版本控制的第一条规则：永远不要将生成的资产提交到您的存储库。所以你绝对不应该将 Boost 和 Poco 的构建产品提交到你的存储库中。是否将依赖项作为源包含在存储库中实际上取决于您；这在某种程度上取决于您的项目、您需要多少依赖项、您的软件有多少公众可能可以轻松访问这些依赖项等。打包者和发行版通常希望您不要捆绑依赖项，而是相反在自述文件或安装文件中仔细提及它们。
如果您想让从 VCS 检查您的代码的人员轻松获取依赖项，请尝试使用 svn externals、git submodules 或 hg subrepos，这样可以轻松排除依赖项并建立到依赖项上游存储库的清晰链接。
First rule of version control: never commit generated assets to your repository. So you should definitely not commit build products of Boost and Poco to your repository. Whether to include dependencies in your repository as source is really up to you; it kind of depends on your project, how many dependencies you need, how much of the public for your software is likely to have easy access to those dependencies, etc. Packagers and distributions generally prefer that you don't bundle your dependencies, but instead carefully mention them in a README or INSTALL file.
If you want to make it easy to get the dependencies for people who check your code from a VCS, try to use svn externals, git submodules or hg subrepos, making it easy to exclude the dependencies and establish a clear link to the dependency's upstream repository.
首先，是否使用 Maven 并不重要。没关系。
现在，我已经解决了这个问题，我建议您使用 Maven 存储库管理器，例如 Nexus 或 Artifactory。
Artifactory 和 Nexus 所做的是为第三方库创建一个网络范围的存储库结构。
您可以使用标准
wget或curl命令轻松下载发布存储库中的任何工件。如果您使用 Ant，则可以使用 Ivy 来管理您的工件。如果您使用 Maven，那么一切就都准备好了。这意味着您可以直接在构建脚本中编写所需第三方库的下载脚本。发布存储库也可用于您的第三方库。您是否制作了您的其他项目使用的基础库？您可以使用相同的发布和下载机制来使编译的对象可供系统使用。
签入第三方库会导致以下问题：
foo库，则foo很可能位于存储库中的两个不同位置。foo的信息。你不会记得它是哪个版本的 foo 。在过去的十年里，我一直是 java 项目的构建工程师，在每个项目中，我们都有一些来自 Foo 项目的 foo.jar，但没有一个开发人员知道它是版本 1.3、2.5 还是 4.5。我们不知道 Foo 项目是否支持这个旧版本，或者我们是否得到了有缺陷的 1.3，并且应该在 Hoover 政府中升级到版本 1.4。顺便说一句，您从未提到过您的编程平台。如果您使用 Ruby、Php 或 Perl，则可以使用它们内置的存储库系统（分别为 Gem、Pear 和 CPAN），并且无需担心配置发布存储库。
First, it doesn't matter if you're using Maven or not. It doesn't matter.
Now, that I have that out of the way, I suggest you use a Maven repository manager like Nexus or Artifactory.
What Artifactory and Nexus do is create a network wide repository structure for third party libraries.
You can easily download any artifact in your release repository with the standard
wgetorcurlcommands. If you use Ant, you can use Ivy to manage your artifacts. If you use Maven, well, you're all set. That means you can script the download of the required third party libraries right in your build scripts.A release repository can also be used for your third party libraries. Do you produce a base library that other projects of yours use? You can use the same release and download mechanism to make your compiled objects available to your system.
Checking in your third party libraries in causes the following issues:
foolibrary, chances are you'll havefoolocated in two different places in your repository.foo. You won't remember which version of foo it was. I've been a build engineer for java projects for the last decade, and in every project we have some foo.jar from the Foo project, and none of the developers know whether it is verison 1.3, 2.5, or 4.5. We have no idea if the Foo project even supports this older version or if we got the buggy 1.3 and should have upgraded to version 1.4 back in the Hoover administration.By the way, you never mentioned your programming platform. If you are using Ruby, Php, or Perl, you can use their built in repository system (Gem, Pear, and CPAN respectively) and you won't need to worry about configuring release repositories.
我喜欢这些第三方库可以通过 git 获得，并且我可以将它们作为子模块包含在我的项目中。我非常喜欢这样。使更新变得轻而易举。
如果这是不可能的，那么是的，我将他们的代码包含在我的存储库中。最终，我将把我的生产分支移交给我的运营人员，以推送到生产服务器，因此它需要拥有运行所需的所有货物。这可能与您的工作流程不同，但这就是我的工作流程。
I like it when those third party libraries are available via git, and I can include them in my project as submodules. I like that a lot. Makes pulling in updates a total piece of cake.
When that's not possible, then yeah, I include their code right in my repo. Ultimately, I'm going to turn my production branch over to my operations people to push to the production server, so it needs to have all the goods needed to run. That may be a different workflow than yours, but that's how mine works.