<p>They already keep *.lock file with library name and revision commit.</p>
<hr/>**评论：**<br/><br/>peterbourgon: <pre><p>There is no right answer. Decide for yourself.</p>
<p><a href="https://github.com/golang/dep/blob/master/FAQ.md#should-i-commit-my-vendor-directory" rel="nofollow">https://github.com/golang/dep/blob/master/FAQ.md#should-i-commit-my-vendor-directory</a></p></pre>jerf: <pre><p>If you are programming professionally, I suggest having a copy of all imports in at least one place in house. Having them checked in is a good way to meet that criterion. This prevents against a lot of scenarios that may individually be low probability, but together add up to something that probably will eventually happen if you continue to grow.</p>
<p>Note that I'm not advocating directly for "always checking in vendor"... I'm specifically referring to having a copy internally. For instance, if you have an internal library that lives on your local source control system, there's obviously not much benefit to having more copies of that just hanging out elsewhere in your system.</p>
<p>As a rule I also try to strive for "I ought to be able to build all projects from scratch without hitting the internet". Again, all sorts of low-probability events (internet is down and you need to rebuild something anyhow, someone takes a project down, someone force-pushes and whacks the commit you used to be able to get, you don't have proper authentication on some internet download and you download malicious code, or someone accidentally set something to "Take latest" version and you get malicious code, etc etc) that are just easier to avoid and deal with if you've got the resources internally.</p></pre>hell_0n_wheel: <pre><p>I'll go a step further than all the good advice in this thread and say <em>you should only build and ship code that's committed to your own repo</em>, including vendor libraries. Reproducible builds is one benefit, but thinking more broadly, you want your entire develop - build - test - deploy pipeline to be completely self-contained, and firewalled from external changes but at the front end. This way, you have much tighter control over exactly when and how changes are introduced. Makes for a more predictable production environment... most of the time. (Murphy was an optimist!)</p></pre>robvdl: <pre><p>No. The whole point of the vendor directory is "what happens if the dependency I depend on disappears".</p>
<p>Though I did read that the rules are different for libraries vs projects.</p></pre>Maksadbek: <pre><p>Yep, projects=libraries</p></pre>SeerUD: <pre><p>I'll echo something another person has said. It depends on what you're building. I have a couple of projects where they are committed, and another where they are not. The ones were they are committed are projects where I want the user to still be able to <em>just</em> run <code>$ go get ...</code> to install it. If that weren't the case, I'd have to start distributing pre-compiled binaries. In libraries however, I may not choose to commit them... again, it depends. You have to judge it a bit on a case-by-case basis.</p></pre>pinpinbo: <pre><p>I think you should add it to git. Keep your deployments as immutable as possible.</p>
<p>During CI process, you may lose internet connectivity, then your deployment would fail.</p></pre>ellotheth: <pre><p><a href="https://github.com/Masterminds/glide/issues/106#issuecomment-148117872" rel="nofollow">From one of the Glide authors</a>:</p>
<blockquote>
<p>What we usually suggest is that you add vendor/ to your gitignore. Then the packages aren't checked into your local project but are instead ignored all together. If someone wants to get the packages they can run glide install and get them. They can even get the versions you specified in your glide.yaml file.</p>
</blockquote>
<p>Glide was influenced by PHP's <a href="https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md" rel="nofollow">Composer</a>, which has a similar recommendation.</p></pre>peterbourgon: <pre><p>I don't think this is good default advice. It means that everybody who wants to build your repo needs to also have glide installed. I don't think that's a good assumption. This is a major reason why having dep be part of the standard tool chain is very important, so that we can make assumptions like this, and/or build the dependency management functionality into other parts of the tool.</p></pre>joeyGibson: <pre><p>It's no different than a Java project assuming you have Maven or Gradle installed. Sometimes, to build something, you have to have a certain tool. </p></pre>peterbourgon: <pre><p>Maven or Gradle are standards in the Java community. There isn't a standard in the Go community for this stuff.</p></pre>ChristophBerger: <pre><p>...yet.</p></pre>ellotheth: <pre><blockquote>
<p>It means that everybody who wants to build your repo needs to also have glide installed. I don't think that's a good assumption.</p>
</blockquote>
<p>It's not an abnormal assumption across the package management ecosystem. Whether it's one you want to make/enforce depends on your project and audience.</p></pre>aboukirev: <pre><p>Generally they don't. <code>go get</code> walks and pulls dependencies as well, just not into vendor subfiolder but onto GOPATH. <code>godep</code> used to rewrite imports, which would break <code>go get</code>. Not anymore.</p></pre>Sphax: <pre><p>I much prefer committing the vendor directory, that way I can be sure that I'll always have the dependencies available even if the repository is unavailable, removed etc.</p>
<p>If it's committed I can also simply go get the repo.</p></pre>GoTheFuckToBed: <pre><p>You should always have a backup. </p></pre>karma_vacuum123: <pre><p>God vendoring is a mess</p></pre>hell_0n_wheel: <pre><p>All you're telling us here is that you haven't spent enough time thinking about the problem to find out why "it's a mess."</p></pre>
