GO 工作区使用

GO 工作区使用

版本支持： 1.18

以 trade-common 为例,当新项目A中需要在trade-common中添加新的api时一般会这样做

方法一

1. 本地修改trade-common仓库代码和单元测试，推送到master分支
2. 项目A更新trade-common版本: go get -u -v trade-common@master
3. 在项目A中测试新方法是否满足需要，如果有问题，需要重新走 1,2 流程

优点：

1. 干净利落，一下搞定

缺点：

1. 本地无法确认新添加的代码是否在项目中无bug运行
2. 同时有其他项目更新了 trade-common ,并使用新添加的方法，不能确认一定无bug

方法二

1. 本地修改trade-common仓库代码和单元测试
2. 在项目A仓库中将依赖仓库替换到本地目录 go mod edit -replace=trade-common@v0.0.1=../trade-common
3. 在项目A中测试新方法，并且能在本地马上得到测试结果
4. 测试无误，回滚掉2中的替换
5. 推送 trade-common 到远程 master 分支
6. 在项目A中更新 trade-common 为最新版

优点：

1. 新添加的方法可以马上验证，没有直接推送到远端，保证了trade-common代码的可用性

缺点:

1. 需要修改项目A的 go.mod 文件，稍不注意忘记回滚就提交到了远程分支了

使用工作区处理

在项目A根目录的上一级目录初始化工作区

$ cd .. && ls -1
demo01
git.myscrm.cn
$ go work init

执行后目录下会生成一个 go.work 文件

$ ls -1
demo01
git.myscrm.cn
go.work

$ cat go.work
go 1.18

将本地的 trade-common 目录添加到工作区中

$ go work use git.myscrm.cn/trade/trade-common
$ cat go.work
go 1.18

use ./git.myscrm.cn/trade/trade-common

这时修改 trade-common 目录中的方法，再运行项目A 中的代码便会实时生效

优点:

1. 不用修改 项目A 下的 go.mod 文件内容
2. trade-common 代码修改后能及时的调试,保证了该仓库远程代码的可用性
3. go.work 不用提交到仓库中，每个开发都可以使用自己本地指定路径

go work

提供对工作区操作的访问。

https://go.dev/ref/mod#go-work-init

$ go help work

Usage:

	go work <command> [arguments]

The commands are:

	edit        edit go.work from tools or scripts
	init        initialize workspace file
	sync        sync workspace build list to modules
	use         add modules to workspace file

1. go work init [moddirs]
   在当前目录下初始化工作区；目录下会生成一个 go.work 文件。

$ go work init m1

$ cat go.work 
go 1.18

use ./m1

1. go work use [-r] moddirs

指定要添加到工作区下的mod目录。-r 参数代表是否递归查找目录。

1. go work edit

编辑work文件

-use=path
使用mod模块目录

-dropuse=path
不使用mod模块目录

-replace=old[@v]=new[@v]
指定模块的新模块与旧模块的替代, 其中版本号（@v）可以被省略。如果旧模块中的版本号（@v)被省略了， 相当于指定了旧模块的所有版本； 如果新模块中的版本号（@v)被省略了，则新模块的路径应该是本地模块根目录，而不是模块路径

-dropreplace=old[@v]
删除给定模块路径和版本对的替换

1. go work sync

将工作区的构建列表同步回工作区的模块