Как разместить Golang проект (набор пакетов) в Github?

Мне не ясно, из руководства Golang, как поставить Golang-код в Github, чтобы впоследствии импортировать этот код в виде пакета из Github.

Это примерное рабочее пространство проекта (структура каталогов) из учебника Golang 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

Итак, что мне нужно сделать, где мне нужно git init в этом рабочем пространстве, чтобы иметь возможность позже:

  • Импортировать только newmath пакет в мой отдельный проект. Таким образом:

    import "github.com/user/newmath"

  • Чтобы получить только hello.exe исполняемый файл.

  • Чтобы получить всю рабочую область проекта (все каталоги: bin, pkg, src).

Ответы

Ответ 1

  • Для пакета newmath он совпадает с (позже 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

    Теперь люди могут делать

    $ go get github.com/username/newmath

    и

    import "github.com/username/newmath"

    теперь должны работать в своих источниках. Пакет будет установлен на автоматически запрашивать.

  • Я предполагаю, что команда hello и newmath не связаны или недостаточно тесно связаны с одним хранилище.

    $ 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

    Теперь люди могут делать

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

    чтобы установить команду hello.

    • Нет смысла публиковать контент $GOPATH/pkg в услуги хостинга.
    • Имеет смысл опубликовать содержимое $GOPATH/bin в службе хостинга. Но я препятствую этой практике для очевидных причины. Кроме того, если вы публикуете источники - двоичные файлы не нужны, и каждый может создавать свои (доверенные) самостоятельно.

Кажется, что вы, вероятно, еще немного смущены термином "рабочее пространство". Рабочее пространство довольно часто существует только один раз на машине разработчика, но оно обычно содержит несколько репозиториев. Некоторые из них разрабатываются разработчиком, а другие "идут в игру" из Интернета. Публиковать целые wokspace в этом случае мало смысла.

Однако есть люди, которые используют отдельное рабочее пространство для каждого проекта или для каждого репозитория или, возможно, даже для каждого пакета. Я не знаю, какие преимущества. Или, лучше сказать, я думаю, что нет никого по сравнению с одним рабочим пространством, определяемым, скажем, export GOPATH=$HOME (как и мой случай в течение многих лет без каких-либо проблем с ним в течение многих лет).

Ответ 2

Проверьте эту ссылку для получения дополнительной информации:

github go wiki в макете github

ниже - постоянный раздел:

Приложение и обе библиотеки живут на Github, каждый в своем собственном репозитории. $GOPATH - это корень проекта - каждый из ваших репозиториев Github будет проверил несколько папок ниже $GOPATH.

Схема вашего кода будет выглядеть так:

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

Каждая папка под src/github.com/jmcvetta/является корнем отдельной проверки git.

Ответ 3

Если вы не являетесь поклонником git cli, тогда все, что вам действительно нужно сделать, это загрузить в github repo через веб-интерфейс. Просто убедитесь, что у вас есть имя вашего пакета с тем же именем, что и репо (нижний регистр), и вам должно быть хорошо идти. Я сделал то же самое с github.com/Digitalblueeye/enroute для моей библиотеки API REST.