Does Go prefer to fetch from remote repository or prefer to use local files?

Let's assume that my entire repository is at both github.com/my_repo and local file system. A source file imports "github.com/my_repo/pkg". When I run go run, does go fetch the remote file and import it, or does it prefer local files?

What if there is a generic remote repository (not github/launchpad/etc), will go prefer to fetch remote repository or prefer to use local files?

'go run' never fetches anything from the net. The only Go command which does that is 'go get'.

As per http://golang.org/doc/code.html#remote

> If the specified package is not present in a workspace, go get will place it inside the first workspace specified by GOPATH. (If the package does already exist, go get skips the remote fetch and behaves the same as go install.)

Or, in other words:

1. Go will check for the package locally in your $GOPATH
2. If it doesn't exist, Go will call go get and fetch it.

This is worth noting if you are expecting a specific version of a repo: go will grab the latest for the version of Go installed. If the repo doesn't have specific tags, it will grab the head from the master branch. It's generally a good idea to note the version of the repo you need somewhere in your version control/documentation to ensure you don't get a later (and potentially breaking) repo.

Note that go get will grab the HEAD of master... and clone your repo in a detached HEAD state.
That means: if you want to add a few commits, you would do so in "no branch" mode.
You need first, before making any local commit of your own, to:

git checkout -b master --track origin/master

Git 1.2 (Q4 2013) will change that: see What's happening in Go tip (2013-09-07):

go get for git repositories

> Relevant CLs: CL 12923043, some more I unfortunately do not have the numbers of.
>
> If you ever used go get on a git repository and later went to look at the actual clone, you might have noticed that HEAD was in a detached state, and that every go get -u would put it back in detached state, with HEAD pointing at a specific commit on a remote branch.
>
> And even though that isn’t technically a problem (you could still just check out the master branch), it would lead to confusion and occasional loss of data when one wasn’t aware of the fact.
>
> In Go 1.2, however, go get will always create a “proper” (as in expected) clone, with an active master branch, and go get -u will use git pull and all its effects, such as aborting in case of conflicts or uncommitted changes.
Old clones from before Go 1.2 will automatically be updated to the new format by go get -u.