我们目前正将一些代码库迁移到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仓库中,如果团队中的其他人检查了这些代码,他们的目录结构将由于分叉而不同.路径中的用户名和import语句将更改.事实上,我们拉动并推动彼此而不是使用集中式回购,这并没有帮助.
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子包处理repo forking？
谢谢.
cre*_*ack 10
包应该总是可以获得(使用go get package),因此99%的时间,您的包将是,github.com/user/reponame并且您始终保持整个项目.
是的,这应该是中央回购和贡献者(内部员工或社区)应该创建对该回购的拉取请求,从不实际对其进行处理.
是的,他们应该在原始文件夹中使用它们的git远程分叉(见下文)
不,是的.您可以为非go-gettable包定义相对导入.也就是说,当你不在你的gopath时,你可以import "./subpackage".但是,如果你去GOPATH,Go会抱怨你混合本地和远程进口.在一般情况下,不要使用相对导入.
分包的分叉是通过分叉主包来处理的.
我将以多个团队成员为例,介绍一个Github回购.
中央回购将是http://github.com/central/repo
这个仓库有像github.com/central/repo/pkg,github.com/central/repo/whatever这样的子仓库.
最简单的方法和恕我直言最好的方法是使用git遥控器.
假设我想为subrepo(或其他任何事情)做出贡献,过程很简单:就像在任何其他语言中一样,分叉回购.
现在,正如您所提到的,您有一个导入存储库的副本,其目标是中央存储库.确实不太实际.这就是为什么(期望简单的小项目),我从来没有go get我的分叉,我go get的中央存储库,转到$GOPATH/src/github.com/central/repo并添加我的遥控器git remote add creack https://github.com/creack/repo
现在我可以处理项目,使用它就像它是中心项目一样,一旦完成,我将我的分支推到我的分支,然后创建一个拉取请求.
在这种情况下,fork只是github上的源的占位符,不使用.