What (revision controlled) vendoring management program do you use?

<p>After using Node, Rust, and C# I&#39;m pretty used to having a standard way of managing dependencies. But now I&#39;m trying to learn Go and there is no such standardization. </p> <p>Looking through <a href="https://github.com/golang/go/wiki/PackageManagementTools">this list of implementations</a> is overwhelming. Which one is best? Preferably one with version locking. </p> <p>How do you all feel about the lack of standardization in this area? </p> <hr/>**评论：**<br/><br/>pierrrre: <pre><p><a href="https://github.com/tools/godep">https://github.com/tools/godep</a></p></pre>natefinch: <pre><p>There are a ton of benefits to using godep, and it&#39;s one of the most used vendoring tools.</p> <p>The major benefit is that it makes <code>go get</code> still work. You vendor, it rewrites the import paths to point to the vendored code, you check that in, and then whenever anyone does go-get, they get all your code and the vendored code, and they don&#39;t even need godep to use your code. The only people who need to use godep are the developers of the project... and even then, they only need to use it when they&#39;re changing the version of an external dependency. Day to day hacking doesn&#39;t require using godep at all.</p> <p>It lets you use the idiomatic go working environment - a single gopath for all projects, with no need to remember to run any commands when switching between projects.</p> <p>As for how I feel about it not being standardized... I think it would be nice to get it standardized, if only so people would stop creating new half-baked solutions every week.</p></pre>R2A2: <pre><p>We&#39;re using godep at work. To begin with I tend to just use it to record/restore dependency versions, but then once a project gets close to production-ready, we switch to <code>godep -r</code>, to rewrite import paths, which removes any build dependency on godep itself or any special gopath trickery. It works very well so far...</p></pre>njpatel: <pre><p>I like gopkg.in as an alternative to the others.</p></pre>natefinch: <pre><p>I really like gopkg.in, but it&#39;s not really the same thing as vendoring. Gopkg.in is a tool for library authors to version their libraries. Vendoring is a tool for application authors to insulate their project from third party library changes.</p></pre>njpatel: <pre><p>Ah - I assumed it could be used by application authors too but, yes, I see now that it still wouldn&#39;t protect you against a bad force-push or any other destructive change to the repo or it&#39;s history.</p> <p><em>edit</em> I a word</p></pre>zeroXten: <pre><p>We&#39;re currently using Gom, but I am experimenting with one I wrote in bash. The idea is to be GitHub fork friendly and avoid having to do import rewriting.</p></pre>garunkel: <pre><p>It says </p> <blockquote> <p>The approach  endorsed by the Go project  is &#34;vendoring&#34; (described below) and godep  is a well-maintained tool for managing vendored dependencies.</p> </blockquote> <p>So go kind of recommends godep</p></pre>MeatTenderizer: <pre><p>Git submodules.</p></pre>: <pre><p>[deleted]</p></pre>eduarto: <pre><p>Then why vendor at all?</p></pre>