我们目前正在将部分代码库移至Go，并为团队中的多个开发人员使用灵活的目录结构进行了一些努力。抱歉，如果这是一个菜鸟问题，但我在其他地方进行过搜索，但没有给出答案。
说我有一个具有以下结构的软件包：
package main
import "username/myproject/subpackage"
func main() {
}
和一个子包：
package subpackage
func main() {
}
这很好用，并且通过阅读Github上的其他人的代码，似乎这是定义子包的公认方法。
请参阅CoreOS源代码作为示例：https : //github.com/coreos/etcd/blob/master/main.go
我的问题是，由于Go的目录结构，这些程序包存储在特定的git repo中，并且如果团队中的其他人签出该代码进行工作，由于分叉，它们的目录结构也会有所不同。路径和导入语句中的用户名将更改。我们彼此拉动而不是使用集中式回购，这无济于事。
package main
import "otherusername/myproject/subpackage" (This line will have to be changed)
func main() {
}
我所读过的所有关于Go的内容都指出了它在团队环境中的可用性，所以我想知道我是否正确地了解了打包系统。
理想情况下，我们希望能够使用相对路径调用子包。我们习惯于使用名称空间，我知道Go没有它们。即：
package main
import "myproject/subpackage"
func main() {
}
但是Go找不到该文件，并且我确定这不是正确的处理方式，因为没有示例在线使用相对路径。
有几个问题：
1）软件包应具有已定义的所有者，并始终将用户名保留为导入路径的一部分吗？
2）此“所有者”存储库是否应为所有代码都应推送到/从中提取的集中存储库（例如公司或组织）？
3）处理代码的其他团队成员是否应该在创建者文件夹/命名空间中而不是在自己的代码/命名空间中使用它？
4）有没有一种方法可以在import语句中定义相对路径，如果可以，为什么没人做呢？是否认为这是不良做法？
5）如何用Go子包处理仓库分叉？
谢谢。
程序包应该始终是可获取的（可与一起使用go get package），因此99％的时间里，您的程序包都会被使用，github.com/user/reponame并且您始终将其保存在整个项目中。
是的，这应该是中央回购，并且贡献者（内部员工或社区）应该创建对该回购的拉取请求，而不是对其进行实际操作。
是的，他们应该在原始文件夹中使用它，并将其git远程分支（请参见下面的内容）
不，是的。您可以为non go-gettable包定义相对导入。也就是说，当您不在自己的小路中时，可以import "./subpackage"。但是，如果转到GOPATH，Go将抱怨您混合了本地和远程导入。在一般情况下，请勿使用相对导入。
子包的派生是通过派生主包来进行的。
我将以一个有多个团队成员的Github存储库为例。
中央仓库将是http://github.com/central/repo
这个仓库有像github.com/central/repo/pkg，github.com/central/repo/whatever这样的子仓库。
最简单的方法和恕我直言，最好的方法是使用git remote。
假设我想为一个子仓库（或其他任何事情）做出贡献，过程很简单：就像其他语言一样，分叉该仓库。
现在，正如您所提到的，您拥有一个带有导入功能的存储库副本，该副本针对中央存储库。确实不是很实用。这就是为什么（希望用于简单的小型项目），我从来没有go get我的叉子，我go get是中央存储库，请转到$GOPATH/src/github.com/central/repo并添加我的遥控器git remote add creack https://github.com/creack/repo
现在，我可以处理该项目，就像将它用作中心项目一样使用它。完成后，我将分支推送到我的fork，然后创建一个pull请求。
在这种情况下，fork只是github上源代码的占位符，没有被使用。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句