How to place Golang project (a set of packages) to Github?

It is not clear for me from Golang tutorial how to put Golang code to Github to be able to import that code as a package from Github later.

This is an example project-workspace (directory structure) from the Golang tutorial http://golang.org/doc/code.html:

bin/
    hello              # command executable
pkg/
    linux_amd64/       # this will reflect your OS and architecture
        github.com/user/
            newmath.a  # package object
src/
    github.com/user/
        hello/
            hello.go   # command source
        newmath/
            sqrt.go    # package source

So, what do I need to do, where do I need to git init in this workspace, to be able later:

1. To import only newmath package into my some separate project. This way:

    import "github.com/user/newmath"
   

2. To get only hello.exe executable.

3. To get the whole project-workspace (all directories: bin, pkg, src).

1. For the package newmath it's the same as (later 2.)

   $ mkdir $GOPATH/src/github.com/username/newmath
   $ cd $GOPATH/src/github.com/username/newmath
   $ git init
   $ ... more git setup
   $ touch sqrt.go
   $ gvim sqrt.go
   $ git add sqrt.go
   $ git commit -a -m 'Inital commit'
   $ git push
   

   Now people can do

   $ go get github.com/username/newmath
   

   and

   import "github.com/username/newmath"

   should now work in their sources. The package will be installed on
   demand automatically.

2. I'll assume that the hello command and the newmath package are
   not related, or not enough tightly related to belong to a single
   repository.

   $ mkdir $GOPATH/src/github.com/username/hello
   $ cd $GOPATH/src/github.com/username/hello
   $ git init
   $ ... more git setup
   $ touch hello.go
   $ gvim hello.go
   $ git add hello.go
   $ git commit -a -m 'Inital commit'
   $ git push
   

   Now people can do

   $ go get github.com/username/hello
   $ go install github.com/username/hello
   

   to install your command hello.

3. • It makes almost no sense to publish the content of $GOPATH/pkg at
     the hosting service.
   • It makes some sense to publish the content of $GOPATH/bin at the hosting service. But I discourage this practice for obvious
     reasons. Additionally, if you're publishing the sources - the
     binaries are not necessary and everybody can build their (trusted)
     own.

You seem to be perhaps still a bit confused by the term 'workspace'. A workspace is quite often existing only once at the developer's machine, yet it the typically contains several repositories. Some authored by the developer, others "go getted" from the Internet. To publish a whole wokspace in this case makes little sense.

However, there are people using a separate workspace per project or per repository or maybe even per package. I don't know what the benefits are. Or better said, I think that there are none compared to the single workspace, defined by, say export GOPATH=$HOME (as is my case for years w/o any trouble with it for years).

Check this link out for more details:

github go wiki on github code layout

below is a permanent section:

> The app and both libraries live on Github, each in its own repository.
> $GOPATH is the root of the project - each of your Github repos will be
> checked out several folders below $GOPATH.
>
> Your code layout would look like this:

$GOPATH/
src/
    github.com/
        jmcvetta/
            useless/
                .git/
                useless.go
                useless_test.go
                README.md
            uselessd/
                .git/
                uselessd.go
                uselessd_test.go
                README.md

> Each folder under src/github.com/jmcvetta/ is the root of a separate git checkout.

If your not a fan of git cli then all you really need to do is upload to github repo via the web interface. Just make sure that you have your package name the same name as the repo (lowercase) and you should be good to go. I did just the same with github.com/Digitalblueeye/enroute for my REST API library.