Supposons que vous ayez un référentiel sur github.com/someone/repoet que vous le fassiez github.com/you/repo. Vous voulez utiliser votre fork au lieu du repo principal, vous faites donc un

go get github.com/you/repo

Désormais, tous les chemins d'importation de ce référentiel seront "cassés", ce qui signifie que s'il y a plusieurs packages dans le référentiel qui se référencent via des URL absolues, ils référenceront la source, pas le fork.

Existe-t-il un meilleur moyen de le cloner manuellement dans le bon chemin?

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

Pour gérer les demandes d'extraction

• bifurquer un référentiel github.com/someone/repoversgithub.com/you/repo
• télécharger le code original: go get github.com/someone/repo
• Soyez là: cd "$(go env GOPATH)/src"/github.com/someone/repo
• activez le téléchargement sur votre fork: git remote add myfork https://github.com/you/repo.git
• importez vos modifications dans votre dépôt: git push myfork

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

Pour utiliser un package dans votre projet

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

Si vous utilisez des modules go . Vous pouvez utiliser la replacedirective

La replacedirective vous permet de fournir un autre chemin d'importation qui pourrait être un autre module situé dans VCS (GitHub ou ailleurs), ou sur votre système de fichiers local avec un chemin de fichier relatif ou absolu. Le nouveau chemin d'importation de la replacedirective est utilisé sans qu'il soit nécessaire de mettre à jour les chemins d'importation dans le code source réel.

Vous pouvez donc faire ci-dessous dans votre fichier 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

où v3.2.1est la balise sur votre repo. Peut également être fait via CLI

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

Une façon de résoudre ce problème est celle suggérée par Ivan Rave et http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html - la manière de bifurquer.

Une autre solution consiste à contourner le comportement du golang . Lorsque vous go get, golang dispose vos répertoires sous le même nom que dans l'URI du référentiel, et c'est là que le problème commence.

Si, à la place, vous émettez le vôtre git clone, vous pouvez cloner votre référentiel sur votre système de fichiers sur un chemin nommé d'après le référentiel d'origine.

En supposant que le référentiel d'origine se trouve github.com/awsome-org/toolet que vous le chargez github.com/awesome-you/tool, vous pouvez:

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 est parfaitement heureux de continuer avec ce dépôt et ne se soucie pas vraiment que certains répertoires supérieurs portent le nom awesome-orgalors que git remote l'est awesome-you. Toutes les importations pour awesome-orgsont résolues via le répertoire que vous venez de créer, qui est votre ensemble de travail local.

Plus longuement, veuillez consulter mon article de blog: Forking Golang repositories sur GitHub et gérer le chemin d'importation

edit : chemin de répertoire fixe

Si votre fork n'est que temporaire (c'est-à-dire que vous avez l'intention de le fusionner), faites simplement votre développement in situ, par exemple dans $GOPATH/src/launchpad.net/goamz.

Vous utilisez ensuite les fonctionnalités du système de contrôle de version (par exemple git remote) pour faire du référentiel amont votre référentiel plutôt que celui d'origine.

Il est plus difficile pour d'autres personnes d'utiliser votre référentiel avec go getmais beaucoup plus facile pour son intégration en amont.

En fait, j'ai un référentiel pour goamz pour lp:~nick-craig-wood/goamz/goamzlequel je développe exactement de cette manière. Peut-être que l'auteur le fusionnera un jour!

Voici un moyen qui fonctionne pour tout le monde:

Utilisez github pour accéder à "my / repo" (juste un exemple):

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

Répétez chaque fois que vous améliorez le code:

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

Pourquoi? Cela vous permet d'avoir votre repo avec lequel tout go getfonctionne. Il vous permet également de maintenir et d'améliorer une branche qui convient à une pull request. Il ne gonfle pas git avec "vendeur", il préserve l'historique, et les outils de construction peuvent en donner un sens.

La réponse à cela est que si vous créez un dépôt avec plusieurs packages, vous devrez renommer tous les chemins d'importation appropriés. C'est en grande partie une bonne chose car vous avez forké tous ces packages et les chemins d'importation devraient refléter cela.

Pour automatiser ce processus, j'ai écrit un petit script. Vous pouvez trouver plus de détails sur mon blog pour ajouter une commande comme "gofork" à votre 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

Utiliser ensemble la vente et les sous-modules

1. Fork la lib sur github (go-mssqldb dans ce cas)
2. Ajoutez un sous - module qui clone votre fork dans votre dossier fournisseur mais qui a le chemin du repo en amont
3. Mettez à jour vos importdéclarations dans votre code source pour qu'elles pointent vers le dossier du fournisseur (sans le vendor/préfixe). Par exemple vendor/bob/lib=>import "bob/lib"

Par exemple

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

mygithubuser=timabell
upstreamgithubuser=denisenkom
librepo=go-mssqldb

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

Pourquoi

Cela résout tous les problèmes dont j'ai entendu parler et que j'ai rencontré en essayant de comprendre cela moi-même.

• Les références de package internes dans la bibliothèque fonctionnent maintenant car le chemin est inchangé depuis l'amont
• Une nouvelle extraction de votre projet fonctionne car le système de sous-modules l'obtient de votre fork au bon commit mais dans le chemin du dossier en amont
• Vous n'avez pas besoin de savoir comment pirater manuellement les chemins ou jouer avec l'outillage go.

Plus d'informations

• https://git-scm.com/book/en/v2/Git-Tools-Submodules
• Comment puis-je corriger le message d'erreur "utilisation d'un package interne non autorisée" lors de l'obtention d'un package golang?
• https://github.com/denisenkom/go-mssqldb/issues/406
• https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment

dans votre Gopkg.tomlfichier, ajoutez ces blocs ci-dessous

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

Donc, il utilisera le fourchu project2à la place degithub.com/globalsign/mgo

Vous pouvez utiliser la commande go get -fpour obtenir un dépôt fourchu