Don't couple your Go code to GitHub

Go's import paths are tied to the URL used to fetch code, and many projects default to hosting provider paths like github.com/owner/repo. That creates a hard coupling: moving repositories to another host forces import-path changes across codebases or leaves users fetching the old location. That migration cost can be large enough that teams keep code on multiple hosting services simultaneously; one example led to a company paying for GitHub, GitLab and Azure DevOps because switching was too disruptive. To address that, Boneclone was created to replicate skeletons across providers, but the deeper fix is to avoid embedding the git host in the import path in the first place.

The recommended solution is to serve Go packages under a custom domain (examples: go.iain.rocks, go.uber.org), and use go-import meta tags so the go tool resolves to the actual git host while humans get redirected. With a domain like go.iain.rocks/boneclone you can point that domain at github.com/thetrueares/boneclone today and change the backend to GitLab later without impacting users. Practical NGINX guidance is provided: detect the go-get=1 query to serve the meta HTML for the go tool, and otherwise issue a permanent redirect to the human-facing repo; include normal SSL/certbot setup. The recommendation is explicit: commercial Go teams should namespace internal packages with custom domains to avoid needless coupling.