我们目前正将一些代码库迁移到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?
感谢。
答案 0 :(得分:8)
套餐应该始终可以获取(使用go get package
),因此99%的时间,您的套餐将是github.com/user/reponame
,并且您始终将其保留在整个项目中。
是的,这应该是中央回购和贡献者(内部员工或社区)应该为该回购创建拉取请求,从不实际对其进行处理。
是的,他们应该在原始文件夹中使用它的git远程分叉(见下文)
不,是的。您可以为非go-gettable包定义相对导入。即如果你不在你的牧场,你可以import "./subpackage"
。但是,如果你去GOPATH,Go会抱怨你混合本地和远程进口。在一般情况下,不要使用相对导入。
分包的分叉是通过分叉主包来处理的。
我将以多个团队成员为例,举一个Github回购。
中央回购将是http://github.com/central/repo
这个仓库有像github.com/central/repo/pkg,github.com/central/repo/whatever这样的子回购。
最简单的方法和恕我直言最好的方法是使用git remote。
让我们说我想为subrepo(或其他任何事情)做出贡献,这个过程很简单:就像在任何其他语言中一样,分叉回购。
现在,正如您所提到的,您拥有导入存储库的副本,该存储库以中央存储库为目标。确实不太实际。
这就是为什么(期望简单的小项目),我从不go get
我的分叉,我go get
中央存储库,转到$GOPATH/src/github.com/central/repo
并添加我的远程git remote add creack https://github.com/creack/repo
现在我可以处理该项目,使用它就像它是中心项目一样,一旦完成,我将我的分支推送到我的分支,然后创建一个拉取请求。
在这种情况下,fork只是github上源的占位符,不会被使用。