Припустимо, у вас є сховище github.com/someone/repoі ви відправте його github.com/you/repo. Ви хочете використовувати свою вилку замість основної репо, тому зробите

go get github.com/you/repo

Тепер усі шляхи імпорту в цьому репо будуть "порушені", тобто якщо в сховищі є кілька пакетів, які посилаються один на одного за допомогою абсолютних URL-адрес, вони посилаються на джерело, а не на вилку.

Чи є кращий спосіб, як клонувати його вручну в потрібний шлях?

git clone git@github.com:you/repo.git $GOPATH/src/github.com/someone/repo

Для обробки запитів на тягу

• видати сховище github.com/someone/repoвgithub.com/you/repo
• завантажити оригінальний код: go get github.com/someone/repo
• будь там: cd "$(go env GOPATH)/src"/github.com/someone/repo
• увімкніть завантаження на вашу виделку: git remote add myfork https://github.com/you/repo.git
• завантажте свої зміни до репо: git push myfork

http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html

Щоб використовувати пакет у своєму проекті

https://github.com/golang/go/wiki/PackageManagementTools

Якщо ви використовуєте модулі go . Ви можете використовувати replaceдирективу

replaceДиректива дозволяє поставити інший шлях імпорту , який може бути інший модуль , розташований в VCS (GitHub або в іншому місці), або в локальній файловій системі з відносним або абсолютним шляхом до файлу. Новий шлях імпорту з replaceдирективи використовується без необхідності оновлення шляхів імпорту у фактичному вихідному коді.

Отже, ви можете зробити це нижче у своєму файлі go.mod

module github.com/yogeshlonkar/openapi-to-postman

go 1.12

require (
    github.com/someone/repo v1.20.0
)

replace github.com/someone/repo => github.com/you/repo v3.2.1

де v3.2.1тег на вашому репо. Також це можна зробити через CLI

go mod edit -replace="github.com/someone/repo@v0.0.0=github.com/you/repo@v1.1.1"

Один із способів вирішити це - запропонований Іваном Рейвом та http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html - спосіб розщеплення.

Інший варіант - це подолати поведінку голангу . Коли ви go get, golang викладає ваші каталоги під тим самим іменем, що і в URI сховища, і ось тут починаються проблеми.

Якщо замість цього ви видаєте свій власний git clone, ви можете клонувати своє сховище у вашу файлову систему на шляху, названому на честь оригінального сховища.

Якщо припустити, що оригінальний сховище знаходиться у ньому, github.com/awsome-org/toolі ви розщедрить його github.com/awesome-you/tool, ви можете:

cd $GOPATH
mkdir -p {src,bin,pkg}
mkdir -p src/github.com/awesome-org/
cd src/github.com/awesome-org/
git clone git@github.com:awesome-you/tool.git # OR: git clone https://github.com/awesome-you/tool.git
cd tool/
go get ./...

golang із задоволенням продовжує працювати з цим сховищем і насправді не хвилює, що у верхній директорії є назва, в awesome-orgтой час як віддалений git awesome-you. Весь імпорт для awesome-orgрезольвується через створений вами каталог, який є вашим локальним робочим набором.

Докладніше, дивіться мій пост у блозі: Розміщення сховищ Golang у GitHub та керування шляхом імпорту

редагувати : фіксований шлях до каталогу

Якщо ваша вилка є лише тимчасовою (тобто ви маєте намір її злиття), тоді просто зробіть свою розробку in situ, наприклад, в $GOPATH/src/launchpad.net/goamz.

Потім ви використовуєте функції системи управління версіями (наприклад git remote), щоб зробити репозиторій верхнього потоку своїм сховищем, а не оригінальним.

Іншим людям стає складніше використовувати ваше сховище, go getале набагато простіше його інтегрувати вгору за потоком.

Насправді у мене є сховище для goamz, в lp:~nick-craig-wood/goamz/goamzякому я розробляю саме таким чином. Можливо, автор одного разу з’єднає його!

Ось спосіб, який працює для всіх:

Використовуйте github для розщеплення на "my / repo" (лише приклад):

go get github.com/my/repo
cd ~/go/src/github.com/my/repo
git branch enhancement
rm -rf .
go get github.com/golang/tools/cmd/gomvpkg/…
gomvpkg <<oldrepo>> ~/go/src/github.com/my/repo
git commit

Повторіть кожен раз, коли ви зробите код кращим:

git commit
git checkout enhancement
git cherry-pick <<commit_id>>
git checkout master

Чому? Це дозволяє мати репо, з яким go getпрацює будь-який . Це також дозволяє підтримувати та покращувати гілку, яка добре підходить для запиту на витяг. Він не розкльовує git з "постачальником", він зберігає історію, і побудувати інструменти можуть сенс цього.

Відповідь на це полягає в тому, що якщо ви роздвоюєте репо з кількома пакетами, вам потрібно буде перейменувати всі відповідні шляхи імпорту. Це багато в чому хороша річ, оскільки ви роздрібнили всі ці пакунки, і шляхи імпорту повинні відобразити це.

Для автоматизації цього процесу я написав невеликий сценарій. Ви можете знайти більш детальну інформацію в моєму блозі, щоб додати команду типу "gofork" у ваш bash.

function gofork() {
  if [ $# -ne 2 ] || [ -z "$1" ] || [ -z "$2" ]; then
    echo 'Usage: gofork yourFork originalModule'
    echo 'Example: gofork github.com/YourName/go-contrib github.com/heirko/go-contrib'
    return
  fi
   echo "Go get fork $1 and replace $2 in GOPATH: $GOPATH"
   go get $1
   go get $2
   currentDir=$PWD
   cd $GOPATH/src/$1
   remote1=$(git config --get remote.origin.url)
   cd $GOPATH/src/$2
   remote2=$(git config --get remote.origin.url)
   cd $currentDir
   rm -rf $GOPATH/src/$2
   mv $GOPATH/src/$1 $GOPATH/src/$2
   cd $GOPATH/src/$2
   git remote add their $remote2
   echo Now in $GOPATH/src/$2 origin remote is $remote1
   echo And in $GOPATH/src/$2 their remote is $remote2
   cd $currentDir
}

export -f gofork

Використовуйте вендингові та субмодулі разом

1. Виділіть lib на github (у цьому випадку go-mssqldb)
2. Додайте підмодуль, який клонує вашу вилку у папці постачальника, але має шлях до репо-виходу за потоком
3. Оновіть importзаяви у вихідному коді, щоб вказати на папку постачальника (не включаючи vendor/префікс). Напр. vendor/bob/lib=>import "bob/lib"

Напр

cd ~/go/src/github.com/myproj

mygithubuser=timabell
upstreamgithubuser=denisenkom
librepo=go-mssqldb

git submodule add "git@github.com:$mygithubuser/$librepo" "vendor/$upstreamgithubuser/$librepo"

Чому?

Це вирішує всі проблеми, про які я чув, і стикався, намагаючись зрозуміти це сам.

• Внутрішні рефреш-пакети в lib тепер працюють, оскільки шлях незмінний від вище за течією
• Свіжий замовлення вашого проекту працює, тому що система підмодуля отримує його з вашого вила на правій фіксації, але у шляху до папки вище
• Вам не потрібно знати, щоб вручну зламати шляхи або возитися з інструментом "go".

Більше інформації

• https://git-scm.com/book/en/v2/Git-Tools-Submodules
• Як я можу виправити повідомлення про помилку "використання внутрішнього пакета заборонено", коли я отримую голанг-пакет?
• https://github.com/denisenkom/go-mssqldb/isissue/406
• https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment

у вашому Gopkg.tomlфайлі додайте цей блок нижче

[[constraint]]
  name = "github.com/globalsign/mgo"
  branch = "master"
  source = "github.com/myfork/project2"

Тож він використовуватиме роздвоєні project2замістьgithub.com/globalsign/mgo

Ви можете скористатися командою, go get -fщоб отримати роздвоєне репо