That depends on the tool you want to use to manage your vendor folder, so no, hellogopher does not enforce an opinion on that.
For example, you could modify the Makefile to run "gvt restore" before building. However, I warmly recommend checking vendor/ in: not doing so requires the user to have gvt (or whatever tool), breaks go get, and adds unnecessary external dependencies (think left-pad).
I see. Guess, bare `go get` just can't get a dependency into `./vendor/` so either a third-party or checking in is required.
Is there any suggestions/best practices how to maintain `vendor/` under the source control? I mean, handling updates, branch merges and all the disaster that accidental local patches may bring - this sort of stuff?
The real problem with go get here is that it can't pick a version, only latest. Checking in vendor is much safer because your dependencies can't break you.
there are no good upstream suggestions on how to deal with vendor.
My preference is to use to use http://glide.sh/ and store 'glide.yaml' and 'glide.lock' in the repo, at which point the vendor folder can be recreated to the correct versions without needing to parse code or checkin vendor.
Glide is also really good at handling updates, pulling from alternate sources, tracking alternate branch names, etc etc.
For example, you could modify the Makefile to run "gvt restore" before building. However, I warmly recommend checking vendor/ in: not doing so requires the user to have gvt (or whatever tool), breaks go get, and adds unnecessary external dependencies (think left-pad).
More details here https://github.com/FiloSottile/gvt#alternative-not-checking-...