Git | Tony Bai

标签 Git 下的文章

Go语言包管理简史

九月 21, 2019
2 条评论

img{512x368}

包管理是Go一直被诟病做得不好的功能之一。先前版本（go 1.11之前）的主要缺点之一是go get是缺乏对依赖包版本的管理和对可复制构建(reproducible build)的支持。Go社区已经开发了一些包管理器和工具作为版本化包依赖的事实标准解决方案，如glide，dep以及一些辅助工具等。

“我在生产构建中使用go get。” – 没有人这么说过。

Go语言的包管理实现可追溯到Google公司内的代码依赖管理（Google将内部所有源代码都存放在一个巨大的单体存储库中）。我们来分析一下在”Go module”之前Go语言的包管理工具都出了什么问题。

依赖包的版本化
依赖包的本地缓存(vendor)
GOPATH的必要性

依赖包的版本化

go get默认情况下不支持包版本控制。go软件包管理的第一版实现背后的想法是-不需要包版本控制，不需要第三方包存储库，您可以从当前分支中构建所有内容。

在Go 1.11之前的版本中，添加依赖项意味着将该依赖项的源代码仓库克隆到$GOPATH下面。就是这样，没有版本的概念。版本始终指向克隆时刻的主分支。出现了另一个主要问题是，当不同的项目需要依赖包的不同版本时，Go包管理工具无法实现。

依赖包的本地缓存(vendor)

依赖包本地缓存通常是指相关依赖包与项目存储在同一位置。这通常意味着将您的依赖项源码也提交到源管理系统中，例如Git。

考虑这样一种情况- A使用依赖项B，而B使用了C版本在1.5版本中引入一个功能，这时B必须确保A在构建时使用的也是C 1.5或更高版本。在Go 1.5之前的版本中，没有一种机制可以在不重写导入路径的情况下将依赖包代码与命令绑定在一起。

GOPATH的必要性

GOPATH存在的主要原因有两个：

在Go中，import声明通过其完全限定的导入路径来引用包。GOPATH存在可以方便Go工具计算GOPATH/src内的任何目录所涉及软件包的绝对导入路径。
它是Go get命令存储包依赖项的位置。

这有什么问题？

GOPATH 不允许开发人员像其他语言一样选择任意喜欢的目录签出项目的源代码。
此外，GOPATH不允许开发人员同时检出某个项目（或其依赖项）的多个副本。

Go Module介绍

Go 1.11引入了对Go模块(module)的初步支持。下面摘自Go Wiki：

一个模块是一组相关的Go包的集合，这个包集合被当做一个独立的单元进行统一版本管理。模块精确记录了依赖要求并支持创建可复制的构建。

Go模块带来了三个重要的内置功能：

go.mod文件，它与package.json或Pipfile文件的功能类似。
机器生成的传递依赖项描述文件 – go.sum。
不再有GOPATH限制。模块可以位于任何路径中。

$ go help mod
Go mod provides access to operations on modules.

Note that support for modules is built into all the go commands,
not just 'go mod'. For example, day-to-day adding, removing, upgrading,
and downgrading of dependencies should be done using 'go get'.
See 'go help modules' for an overview of module functionality.

Usage:

    go mod <command> [arguments]

The commands are:

    download    download modules to local cache
    edit        edit go.mod from tools or scripts
    graph       print module requirement graph
    init        initialize new module in current directory
    tidy        add missing and remove unused modules
    vendor      make vendored copy of dependencies
    verify      verify dependencies have expected content
    why         explain why packages or modules are needed

Use "go help mod <command>" for more information about a command.

更多相关讨论在这里。

迁移到Go Module

要使用Go模块，请更新Go到1.11及以上版本。由于不再需要GOPATH，因此可以通过以下两种方式之一激活模块支持(译注：下面的行为仅适用于Go 1.11~Go 1.12，Go 1.13版本默认开启Go module，无论是否在GOPATH下，除非GO111MODULE=off)：

在GOPATH/src之外的目录中调用Go命令，并在当前目录中存在一个有效的go.mod文件。
如果源码在GOPATH之下，Go模块将不起作用。要改变此行为，请设置环境变量GO111MODULE=on后再调用Go命令。

让我们通过以下简单的步骤开始迁移：

由于GOPATH不再必要的了，将module移出GOPATH。
在项目根目录中，创建初始模块定义 – go mod init github.com/username/repository。go mod还会自动转换现有的包管理器（如dep和Gopkg，glide以及其他六种）的依赖关系。这将创建一个名为go.mod的文件，该文件存储了模块名以及模块的依赖项及其版本。

$ cat go.mod
module github.com/deepsourcelabs/cli

go 1.12

require (
    github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e
    github.com/getsentry/raven-go v0.2.0
    github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9
)

运行go build会创建一个go.sum文件，其中包含特定模块版本的内容的预期校验和。这是为了确保这些模块将来的下载内容与第一次下载是相同的。请注意，go.sum不是锁文件。

$ cat go.sum
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e h1:9574pc8MX6rF/QyO14SPHhM5KKIOo9fkb/1ifuYMTKU=
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e/go.mod h1:GJKEexRPVJrBSOjoqN5VNOIKJ5Q3RViH6eu3puDRwx4=
github.com/getsentry/raven-go v0.2.0 h1:no+xWJRb5ZI7eE8TWgIq1jLulQiIoLG0IfYxv5JYMGs=
github.com/getsentry/raven-go v0.2.0/go.mod h1:KungGk8q33+aIAZUIVWZDr2OfAEBsO49PX4NzFV5kcQ=
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9 h1:dIsTcVF0w9viTLHXUEkDI7cXITMe+M/MRRM2MwisVow=
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=

关于版本控制的注意事项：为了保持向后兼容性，如果模块的版本为v2或更高版本，则模板的主版本必须以/vN的形式被包含在go.mod文件中使用的模块路径的末尾。比如：module github.com/username/repository/v2

日常命令

列出依赖项

go list -m all 列出当前模块及其所有依赖项。

$ go list -m all
github.com/deepsourcelabs/cli
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e
github.com/getsentry/raven-go v0.2.0
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9

在go list输出中，当前模块（也称为主模块）始终是第一行，其后是路径排序所有依赖模块。

列出软件包的可用版本

go list -m -versions github.com/username/repository 列出软件包的可用版本。

$ go list -m -versions github.com/getsentry/raven-go
github.com/getsentry/raven-go v0.1.0 v0.1.1 v0.1.2 v0.2.0

添加依赖

添加依赖项是隐式的。在代码中导入依赖项后，运行go build或go test命令将获取模块的最新版本并将其添加到go.mod文件中。如果要显式添加依赖项，请运行go get github.com/username/repository。

依赖项的升级/降级

go get github.com/username/repository@vx.x.x下载并设置依赖项和更新go.mod文件的特定版本。

$ go get github.com/getsentry/raven-go@v0.1.2
go: finding github.com/getsentry/raven-go v0.1.2
go: downloading github.com/getsentry/raven-go v0.1.2
go: extracting github.com/getsentry/raven-go v0.1.2

$ cat go.mod
module github.com/deepsourcelabs/marvin-go

go 1.12

require (
    github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e
    github.com/getsentry/raven-go v0.1.2
    github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9
)

$ cat go.sum
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e h1:9574pc8MX6rF/QyO14SPHhM5KKIOo9fkb/1ifuYMTKU=
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e/go.mod h1:GJKEexRPVJrBSOjoqN5VNOIKJ5Q3RViH6eu3puDRwx4=
github.com/getsentry/raven-go v0.1.2 h1:4V0z512S5mZXiBvmW2RbuZBSIY1sEdMNsPjpx2zwtSE=
github.com/getsentry/raven-go v0.1.2/go.mod h1:KungGk8q33+aIAZUIVWZDr2OfAEBsO49PX4NzFV5kcQ=
github.com/getsentry/raven-go v0.2.0 h1:no+xWJRb5ZI7eE8TWgIq1jLulQiIoLG0IfYxv5JYMGs=
github.com/getsentry/raven-go v0.2.0/go.mod h1:KungGk8q33+aIAZUIVWZDr2OfAEBsO49PX4NzFV5kcQ=
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9 h1:dIsTcVF0w9viTLHXUEkDI7cXITMe+M/MRRM2MwisVow=
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=

vendor依赖项

使用模块时，go命令将完全忽略vendor目录。为了向后兼容旧版Go，或确保将用于构建的所有文件一起存储在单个文件树中，请运行go mod vendor。

这将在主模块的根目录中创建一个vendor目录，并将依赖模块中的所有软件包存储在该目录中。

注意：要使用主模块的顶级vendor目录进行构建，请运行’go build -mod=vendor’。

删除未使用的依赖项

go mod tidy将删除未使用的依赖项并更新go.mod文件。

常见问题解答

GOPATH不再需要了？
是，永别了GOPATH。
默认情况下拉取哪个版本？
go.mod文件和go命令通常将语义版本用作描述模块版本的标准形式，以便可以比较版本以确定哪个版本应早于或晚于其他版本。v1.2.3通过在基础源存储库中标记(tag)修订来引入类似的模块版本。未标记(untag)的修订版可以使用“伪版本”之类的来引用：v0.0.0-yyyymmddhhmmss-abcdefabcdef，其中时间是UTC的提交时间，最后的后缀是提交哈希的前缀。
go.sum应该被检入到版本库中吗？
是。

鉴于本人近期较忙，又不希望让博客长草，近一段时间会挑选翻译一些笔者认为比较优秀的外文文章分享给大家。

本文翻译自《Package management in Go – brief overview of package management in Go — pre and post Go modules》。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展；短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

使用git操作svn仓库

六月 25, 2019
2 条评论

如今，虽然Git已经大行其道，但是仍有很多IT公司和组织依旧在使用集中式的版本控制系统subversion，尤其是一些传统软件公司，他们倾向于集中式的联网开发。如果你是一个Git fans，并且你要是遇到代码仓库依旧是使用subversion进行版本控制的情况，你又该如何施展呢？

其实git很早就支持与subversion repo的互操作了，2011年我就曾写过一篇《小试git-svn》的博文，也正是那一年，我第一次使用git操作subversion仓库。

《小试git-svn》一文仅是通过文字性描述简要说明了git操作svn repo的基本命令和功能，并未结合实际例子，也缺少直观的图片展示，并且未涉及branch和tag的操作。这里打算再写一篇关于使用git操作svn仓库的文章，相比于前者，我期望该文能更为系统并结合demo图文并茂的把使用git操作svn仓库这个事情讲的更形象和透彻一些。

一. 使用git操作svn repo的基本工作流

使用git操作svn repo的多数场景是已经存在一个svn repo，git fans想用git命令与之交互。下图展示了使用git操作这样的svn repo的基本工作流：

img{512x368}

下面我们就用一个demo来详细地说明一下这个基本工作流。

1. 建立一个svn demo库

自己搭建一个svn server还是比较费力的，我们选择一个在线的svn代码托管SaaS服务：svnbucket.com。我们在svnbucket.com上注册账号并创建一个svn repo：test-git-svn，该repo采用标准的项目布局(trunk/branches/tags)：

img{512x368}

接下来我们就开始git操作svn repo的过程！

2. 通过git首次获取svn仓库

git是分布式版本管理工具，无论是git repo还是svn repo，如果要用git操作，那么首先需要获取到repo的所有数据。git提供了svn子命令来操作远程的svn repo库，我们看一下首次获取svn repo信息的过程：

$git svn clone svn://svnbucket.com/bigwhite/test-git-svn/
Initialized empty Git repository in /Users/tony/Test/git-svn-test/test-git-svn/.git/
W: +empty_dir: branches
W: +empty_dir: tags
W: +empty_dir: trunk
r1 = 8cfdc2f6059ff06f53c83d64518dcba146722c04 (refs/remotes/git-svn)
Checked out HEAD:
  svn://svnbucket.com/bigwhite/test-git-svn r1
creating empty directory: branches
creating empty directory: tags
creating empty directory: trunk

$tree ./test-git-svn
./test-git-svn
├── branches
├── tags
└── trunk

3 directories, 0 files
$cd test-git-svn
$git branch -a
* master
  remotes/git-svn

可以看到：我们通过git svn clone(注意：不是git clone)将远程server上的svn repo下载到了本地，后续我们就可以在本地host上快乐地使用git管理本地的代码了。

3. 从svn repo中同步最新的代码变更

接下来，远程的svn仓库经常会发生了变更，某开发人员向svn仓库提交了一些initial code，比如在trunk下建立git-svn-demo目录，并创建go.mod和main.go：

//在svn repo中的trunk/git-svn-demo目录下：

$cat main.go
package main

import "fmt"

func main() {
    fmt.Println("git-svn-demo initial version")
}

$cat go.mod
module github.com/bigwhite/git-svn-demo

如果我们本地使用svn工具，我们只需在联网的情况下通过svn update命令即可将远程svn repo的最新改动同步到本地working copy中。但在git下，我们不能像git repo同步那样使用git pull来同步，而是需要使用git svn rebase来获取svn repo中的最新更新，并rebase我们的工作目录(working copy)：

 $git svn rebase
    A    trunk/git-svn-demo/go.mod
    A    trunk/git-svn-demo/main.go
r2 = f826b74bfff2799deaafbca81354c38e0862509c (refs/remotes/git-svn)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/git-svn.

$tree .
.
├── branches
├── tags
└── trunk
    └── git-svn-demo
        ├── go.mod
        └── main.go

4 directories, 2 files

git svn rebase子命令会根据svn上的revision创建对应的commit，这一命令几乎等效于”svn update”，同样也可能会存在远程svn repo中的代码与git repo冲突的可能性，解决冲突的方法在《小试git-svn》中已经做了描述，这里就不赘述了。

4. 将代码更新推送到远程svn repo

在这种模式下，本地开发已经完全变成了基于git的开发模式，开发者可以自由地发挥git的各种优势了，再也不用担心本地代码没有版本控制而出现各种“误删除”、“意外覆盖”的情况了。开发测试并提交(只需普通git commit)到local git repo后，最终还是要将这些commit推送到远程的svn repo中。这里我们不能用push，而要用git svn dcommit：

// 本地git repo中更新后的main.go

$cat main.go
package main

import "fmt"

func main() {
    fmt.Println("git-svn-demo: git-svn dcommit v0")
}

先提交到git本地的仓库:

$git commit -m"[git svn]: first commit" .
[master be36a7f] [git svn]: first commit
 1 file changed, 1 insertion(+), 1 deletion(-)

然后再“推送”到远程的svn 仓库：

$git svn dcommit
Committing to svn://svnbucket.com/bigwhite/test-git-svn ...
    M    trunk/git-svn-demo/main.go
Committed r3
    M    trunk/git-svn-demo/main.go
r3 = e35efbe999cd035b2d5d67886c9a786ef86c681e (refs/remotes/git-svn)
No changes between be36a7f1164b73a994f28ee3b0e0bb711b5ba2ff and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn

dcommit会将git repo当前branch与远程svn repo中的差异的git commit都提交到svn repo，并为每个git commit生成一个对应的svn revision。这和”git push”很类似。

我们再来本地做两次git commit：

$git commit -m"[git svn]: commit #2" .

$git commit -m"[git svn]: commit #3" .

dcommit到svn repo：

$git svn dcommit
Committing to svn://svnbucket.com/bigwhite/test-git-svn ...
    M    trunk/git-svn-demo/main.go
Committed r4
    M    trunk/git-svn-demo/main.go
r4 = c997db60e3d82c97ce8da23b308d611005740844 (refs/remotes/git-svn)
    M    trunk/git-svn-demo/main.go
Committed r5
    M    trunk/git-svn-demo/main.go
r5 = 3b6215a3e5ae0659743e1e8063f842448c19147c (refs/remotes/git-svn)
No changes between ee0df22b9f41882518a7c7b975c38924a9422395 and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn

我们看到git svn为每个commit生成一个对应的svn revision(svn版本号），这里是r4、r5。

二. 利用git branch的优势

和svn建立branch的“重量级”操作（文件copy）相比，git的branch创建和切换可谓“超轻量级”。因此在日常使用git中，多数开发者都会充分发挥git branch的优势，通过在不同branch上的操作、分支的merge等来减少对master的并发修改带来冲突的影响。

我们经常使用feature branch或bugfix branch。以feature branch为例，在feature branch上一般会有多个commit。但在merge到master分支时，我们可以选择多种merge策略，或是fast forward，或是多个commit自动合并为一个commit，又或git merge支持–squash策略（即只merge代码到本地Working copy，不commit到git repo，后续可作为一个commit手工提交到git repo）。

我个人在用git操作svn repo库时，在git本地开发中，更倾向于使用git merge –squash的方法，因为在feature branch上，我更喜欢频繁的小变更的提交，导致commit很多。如果这些commit都dcommit到svn库，可能让svn commit history项目过多，有些commit甚至没有比较完善的意义。

我们在上面的demo上演示一下这个过程。

在本地建立新分支：feature-branch-1：

$git checkout -b feature-branch-1
Switched to a new branch 'feature-branch-1'

在feature-branch-1做两次修改并commit：

$git commit -m"add foo" .
[feature-branch-1 d12ca00] add foo
 1 file changed, 4 insertions(+)

$git commit -m"add bar" .
[feature-branch-1 160e5ed] add bar
 1 file changed, 4 insertions(+)

回到master分支，merge feature分支的修改，并合并为本地的一次commit：

 $git checkout master
Switched to branch 'master'

$git merge feature-branch-1 --squash
Updating 3b6215a..160e5ed
Fast-forward
Squash commit -- not updating HEAD
 trunk/git-svn-demo/main.go | 8 ++++++++
 1 file changed, 8 insertions(+)

$git commit -m"[git svn]: add foo and bar function" .
[master fe8f153] add foo and bar function
 1 file changed, 8 insertions(+)

接下来，将这次合并的commit同步到svn repo上：

$git svn dcommit
Committing to svn://svnbucket.com/bigwhite/test-git-svn ...
    M    trunk/git-svn-demo/main.go
Committed r6
    M    trunk/git-svn-demo/main.go
r6 = 37bbfbdb99cb7331057a05b72dc55b3faf55b645 (refs/remotes/git-svn)
No changes between fe8f153cac62e027ca068fdd55c2bdaa8751aaf8 and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn

三. 通过git为svn库建立branch和打tag

通过git为svn repo建立branch和tag这类操作其实并没有体现出git的优势，因此日常开发人员一般会用svn命令直接操作svn repo，而不是用git svn子命令。但这里我们仍然要介绍一下通过git为svn repo建立branch和tag的方法。

我们先来看看创建branch：

$git svn branch feature-branch-1-from-git
Multiple branch paths defined for Subversion repository.
You must specify where you want to create the branch with the --destination argument.

我们看到git svn branch命令出错：让我们指定–destination参数，那我们就再来一遍：

 $git svn  branch feature-branch-1-from-git --destination=branches
Unknown branch destination branches

依旧报错！似乎git不认识“branches”这个存放branch的目录！要想解决这个问题，我们需要对.git/config中的配置做些变更，添加最后两行：

$cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = true
[svn-remote "svn"]
        url = svn://svnbucket.com/bigwhite/test-git-svn
        fetch = :refs/remotes/git-svn
        branches = branches/*:refs/remotes/*
        tags = tags/*:refs/remotes/*

原先的.git/config中并没有设置branhes和tags的入口。我们再来试一下建立branch：

git svn --username=bigwhite  branch feature-branch-1-from-git
Copying svn://svnbucket.com/bigwhite/test-git-svn at r8 to svn://svnbucket.com/bigwhite/test-git-svn/branches/feature-branch-1-from-git...
Authorization failed: Unable to connect to a repository at URL 'svn://svnbucket.com/bigwhite/test-git-svn': Can't get password at /usr/local/Cellar/git/2.12.2/libexec/git-core/git-svn line 1200.

仍然报错！不过这个错误应该是git（我使用的是2.12.2版本）的一个bug，我们用try-run方式运行的结果却是一切ok的：

$git svn --username=bigwhite -n branch feature-branch-1-from-git
Copying svn://svnbucket.com/bigwhite/test-git-svn at r8 to svn://svnbucket.com/bigwhite/test-git-svn/branches/feature-branch-1-from-git...

打tag的方式与建立 branch的方式类似：

 $git svn tag v1.0.0 -n  -m "[git svn]: tag v1.0.0" --destination=tags
Copying svn://svnbucket.com/bigwhite/test-git-svn at r5 to svn://svnbucket.com/bigwhite/test-git-svn/tags/v1.0.0...

四. 小结

git svn子命令是git fans操作svn repo的利器。由于git svn clone svn_repo后的repo就是一个标准的本地git repo，因此我们还可以为该git repo建立remote upstream repo，这样就可以在local git repo、remote git repo以及remote svn repo三者之间进行代码变更的同步了，当然这种场景操作还是蛮复杂的，也相对少见。

个人建议，无论个人还是组织，即便使用svn中心repo，在本地也尽量用git来进行源码版本管理，并通过git svn与中心svn repo互操作。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

标签 Git 下的文章

Go语言包管理简史

依赖包的版本化

依赖包的本地缓存(vendor)

GOPATH的必要性

Go Module介绍

迁移到Go Module

日常命令

列出依赖项

列出软件包的可用版本

添加依赖

依赖项的升级/降级

vendor依赖项

删除未使用的依赖项

常见问题解答

使用git操作svn仓库

一. 使用git操作svn repo的基本工作流

1. 建立一个svn demo库

2. 通过git首次获取svn仓库

3. 从svn repo中同步最新的代码变更

4. 将代码更新推送到远程svn repo

二. 利用git branch的优势

三. 通过git为svn库建立branch和打tag

四. 小结

欢迎使用邮件订阅我的博客

文章

评论

分类

归档

链接

开源项目

翻译项目