Załóżmy, że masz repozytorium pod adresem github.com/someone/repoi rozwidlasz je do github.com/you/repo. Chcesz użyć forka zamiast głównego repozytorium, więc wykonaj plik

go get github.com/you/repo

Teraz wszystkie ścieżki importu w tym repozytorium będą „zepsute”, co oznacza, że ​​jeśli w repozytorium znajduje się wiele pakietów, które odwołują się do siebie poprzez bezwzględne adresy URL, będą one odnosić się do źródła, a nie do rozwidlenia.

Czy jest lepszy sposób, niż ręczne sklonowanie go do właściwej ścieżki?

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

Do obsługi żądań ściągnięcia

• rozwidlić repozytorium github.com/someone/repodogithub.com/you/repo
• pobierz oryginalny kod: go get github.com/someone/repo
• bądź tam: cd "$(go env GOPATH)/src"/github.com/someone/repo
• włącz przesyłanie do swojego forka: git remote add myfork https://github.com/you/repo.git
• prześlij zmiany do repozytorium: git push myfork

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

Aby użyć pakietu w swoim projekcie

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

Jeśli używasz modułów go . Możesz użyć replacedyrektywy

replaceDyrektywa pozwala dostarczyć inną ścieżkę importu, które mogłyby być inny moduł znajduje się w VCS (GitHub lub gdzie indziej), lub w lokalnym systemie plików z bezwzględną lub względną ścieżkę do pliku. Nowa ścieżka importu z replacedyrektywy jest używana bez konieczności aktualizowania ścieżek importu w rzeczywistym kodzie źródłowym.

Możesz więc zrobić to poniżej w swoim pliku 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

gdzie v3.2.1jest tag w twoim repozytorium. Można to również zrobić przez CLI

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

Jednym ze sposobów rozwiązania tego problemu jest metoda zaproponowana przez Ivana Rave'a i http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html - sposób rozwidlenia.

Innym jest obejście zachowania golang . Kiedy ty go get, golang układa twoje katalogi pod taką samą nazwą jak w identyfikatorze URI repozytorium, i tutaj zaczyna się problem.

Jeśli zamiast tego wydasz własne git clone, możesz sklonować swoje repozytorium do swojego systemu plików na ścieżce nazwanej tak, jak oryginalne repozytorium.

Zakładając, że oryginalne repozytorium jest dostępne github.com/awsome-org/tooli rozwidlasz je github.com/awesome-you/tool, możesz:

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 jest całkowicie zadowolony z kontynuowania tego repozytorium i właściwie nie obchodzi go, że jakiś górny katalog ma taką nazwę, awesome-orgpodczas gdy zdalny git ma taką nazwę awesome-you. Cały import dlaawesome-org pliki są ponownie wyszukiwane za pośrednictwem właśnie utworzonego katalogu, który jest lokalnym zestawem roboczym.

Szerzej , zobacz mój wpis na blogu: Rozwidlenie repozytoriów Golang na GitHub i zarządzanie ścieżką importu

edit : stała ścieżka katalogu

Jeśli twój fork jest tylko tymczasowy (tj. Zamierzasz go scalić), po prostu zrób swój rozwój in situ, np. In $GOPATH/src/launchpad.net/goamz . .

Następnie używasz funkcji systemu kontroli wersji (np. git remote), Aby uczynić z repozytorium nadrzędnego repozytorium zamiast oryginalnego.

Utrudnia to innym osobom korzystanie z twojego repozytorium, go getale znacznie ułatwia jego integrację z nadrzędnym.

W rzeczywistości mam repozytorium dla goamz, w lp:~nick-craig-wood/goamz/goamzktórym rozwijam się dokładnie w ten sposób. Może autor kiedyś to połączy!

Oto sposób, aby to działało dla każdego:

Użyj github, aby rozwidlić do „my / repo” (tylko przykład):

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

Powtarzaj za każdym razem, gdy ulepszysz kod:

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

Czemu? Dzięki temu masz repozytorium, go getz którym współpracuje. Pozwala również utrzymywać i ulepszać gałąź, która jest dobra dla żądania ściągnięcia. Nie nadyma gita „dostawcą”, zachowuje historię, a narzędzia do budowania mogą to nadać sens.

Odpowiedź jest taka, że ​​jeśli rozwidlisz repozytorium z wieloma pakietami, będziesz musiał zmienić nazwy wszystkich odpowiednich ścieżek importu. Jest to w dużej mierze dobra rzecz, ponieważ wszystkie te pakiety zostały rozwidlone, a ścieżki importu powinny to odzwierciedlać.

Aby zautomatyzować ten proces, napisałem mały skrypt. Możesz znaleźć więcej szczegółów na moim blogu, aby dodać polecenie typu „gofork” do swojego basha.

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

Korzystaj ze sprzedaży i modułów podrzędnych razem

1. Rozwidlaj bibliotekę na github (w tym przypadku go-mssqldb)
2. Dodaj podmoduł, który klonuje twój fork do folderu dostawcy, ale ma ścieżkę do repozytorium
3. Zaktualizuj swoje importinstrukcje w kodzie źródłowym, aby wskazywały folder dostawcy (bez vendor/prefiksu). Np. vendor/bob/lib=>import "bob/lib"

Na przykład

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

mygithubuser=timabell
upstreamgithubuser=denisenkom
librepo=go-mssqldb

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

Czemu

To rozwiązuje wszystkie problemy, o których słyszałem i napotkałem, próbując rozwiązać to samodzielnie.

• Odniesienia do pakietów wewnętrznych w bibliotece działają teraz, ponieważ ścieżka pozostaje niezmieniona w stosunku do nadawcy
• Nowe pobranie twojego projektu działa, ponieważ system podmodułów pobiera go z twojego rozwidlenia po odpowiednim zatwierdzeniu, ale w ścieżce folderu nadrzędnego
• Nie musisz wiedzieć, jak ręcznie zhakować ścieżki lub zepsuć narzędzia do uruchamiania.

Więcej informacji

• https://git-scm.com/book/en/v2/Git-Tools-Submodules
• Jak naprawić komunikat o błędzie „użycie wewnętrznego pakietu jest niedozwolone” podczas pobierania pakietu golang?
• https://github.com/denisenkom/go-mssqldb/issues/406
• https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment

w swoim Gopkg.tomlpliku dodaj te bloki poniżej

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

Więc użyje rozwidlenia project2zamiastgithub.com/globalsign/mgo

Możesz użyć polecenia, go get -faby uzyskać rozwidlone repozytorium