'Don't include "sensitive" configs in your Git repos' should be the correct title. With regards to external dependencies, Vendoring is a source of debate and I

'Don't include "sensitive" configs in your Git repos' should be the correct title. With regards to external dependencies, Vendoring is a source of debate and I don't think the larger community agrees on one rather than the other. More recently, Golang recommends Vendoring, and last I heard, refuse to support dependency management, so if anything you should look at their arguments for doing so. https://www.reddit.com/r/golang/comments/2xpulb/the_go_team_officially_recommends_vendoring/ https://www.reddit.com/r/golang/comments/2xpulb/the_go_team_... I do thing this is important to absorb though: Point 1 - a build must always be reproducible and deterministic. Point 2 - a build that pulls in external dependencies relies on its external dependencies to be reproducible and deterministic. When Point 2 is not 100% certain (reliability, changeable artifacts), Point 1 goes out the window. Therefore, Vendoring is a crucial strategy from a build engineering perspective. The most common strategy to mitigate this in a non-vendored build is to have control over the external dependencies by deploying your own dependency platform for your organisation. The latest Artifactory, for example, has proxy support for many mainstream artifact repositories (gems, eggs, dockers, images, modules, bowers, etc.). Now... this project I inherited has had modifications made to the vendored dependencies... smashes desk with head