怎么他们都有开源项目经历｜手把手教你参与开源

一、前言

大家好，这里是白泽。有一些同学提问，希望在自己的简历上增加一些有含金量的项目经历，最好能够去参与一些开源项目的开发，但由于对一个庞大的开源项目缺乏认知，难以着手。同时也担心自己能力不足，不知道自己写的代码是否会被接纳。

这里我总结了遇到的一些问题：

如何找到适合我自己的开源项目？白泽你能帮帮我吗！
确定了项目，在项目中如何找到自己能做的需求？白泽你能帮帮我吗！
找到了需求，如何阅读开源项目的代码？白泽你能帮帮我吗！
写完了代码，提交代码的流程是什么样的？白泽你能帮帮我吗！

必须能！

耐心看完这篇文章，你会发现其实参与开源并不遥不可及。在文章的后半部分，白泽将分享自己在不同社区参与的一些开源和之前在 Gitea (GitHub🌟40.3k) 公司实习的一段时光。

公众号「白泽talk」，白泽开源了一个 Go 学习仓库：包含我写作的 Go 各阶段学习文章、读书笔记、电子书、简历模板等，欢迎 star。最近在仓库中一并开源了一个挂机冒险游戏：《模拟龙生》，正在迭代中，欢迎大家试玩，欢迎 pr。

白泽目前正在打造一个氛围良好的行业交流群（游戏交流群），文章的更新也会提前预告，欢迎加入：622383022。

二、如何参与开源

2.1 如何找到适合自己的开源项目

2.1.1 项目检索

出发点：首先选择的开源仓库需要适配自己的方向，最好是自己在做什么项目，会用到某开源项目比较有价值，再去尝试了解和贡献。

为了学习而学习非上上之选，最好是有需求为出发点。

信息检索渠道：GitHub 中文社区

在 GitHub 中文社区，点击左侧菜单栏的索引，便可以跳转至分类检索目录，选择自己感兴趣的方向。

2.1.2 后端项目推荐

🌟 下面这些绝大部分都是白泽参与过开源或者深度使用过的仓库，十分推荐：

Kitex：高性能、扩展性强的 Golang RPC 框架。（star 6.5k 字节跳动）
Hertz：一个高可用性、高性能和高扩展性的 Golang HTTP 框架（star 4.5k 字节跳动）
Gitea：这个项目的目标是以最简单、最快捷、最省力的方式建立一个自我托管的 Git 服务。（star 40.3k）
Woodpecker：一个简单而强大的 CI/CD 引擎，具有很强的可扩展性。（star 3.4k）

🌟 推荐的理由：

首先 Kitex、Hertz 是字节云原生开源社区 cloudwego 中，Go 语言的两个核心框架，当然还有 Rust 的 Volo 框架。白泽自己也是 Hertz 一位认证的 Committer。

围绕这两个仓库的生态十分丰富，社区活跃度很高，加上字节背书，又比较年轻，去年才开源年满两周年，初期学习成本不会非常高，并且 Go 云原生相关也是当下发展的热门方向，所以学习的性价比还是比较高的。 （社区仓库有飞书群二维码）
Gitea 是我去实习之后开始接触的，这个仓库用户极多，非常活跃，社区版也有 Gitea 的员工把持维护，核心开发者在群聊中回复及时，基本可以随时交流，也是很棒的一个社区！ （社区仓库有Q群二维码）
Woodpecker 是 CI 引擎，用 Go 的协程控制容器启动去运行各种任务（代码检查、单元测试、构建…），面向的是真正的一个发挥 Go 语言协程性能的工作场景，因此学习 Go 它是十分合适的。

《使用 Woodpecker 与 Gitea 搭建纯开源的 CI 流程｜极限降本》 我的这篇文章就讲了如何整合 Woodpecker 与 Gitea。

2.2 在开源仓库接受需求

以 HTTP 框架 Hertz 主仓库为例，我们进入 Issues 查看有哪些代办的事项。

这里看到打有 good first issue 的 tag 的需求，就是新手可以尝试参与的。同时关注一下右侧的评论数，如果没有人评论，说明这个需求还是无人认领状态，你可以去评论 please assign me，获得提问者的开发授权。

🌟 白泽找到了一个非常适合新手的任务，“为项目编写单测”，详见这个 issue # 257：

Issue 描述：

单测必须是有意义的
推荐为单元测试添加注释
每一个单测都必须使用断言而不是 print 验证

2.3 阅读开源仓库代码

可以参考白泽之前写作的关于分析 Kitex 框架的文章（下文先以查看这个单测需求为场景进行分析）：

《Kitex源码阅读——脚手架代码是如何通过命令行生成的(一)》
《Kitex源码阅读——脚手架代码是如何通过命令行生成的(二)》

克隆 Hertz 代码到本地：

git clone git@github.com:cloudwego/hertz.git

针对这个添加单测的 issue，pkg/route 部分还没有分配，那么我们进入这部分的代码进行查看：

// HTTP 框架 Hertz 的核心结构内的核心字段就是 *route.Engine
type Hertz struct {*route.EnginesignalWaiter func(err chan error) error
}

🌟 由 Hertz 结构体内包含了 route.Engine 可知，pkg/route 包中的内容是整个 Hertz 框架的核心，涉及大量内容，或许这也是这部分需求没有被社区同学分配掉的原因。

查看一下当前模块的单测覆盖率与85%目标值的差距：

# /pkg/router
baize@baizedeMacBook-Air route % go test -cover ./...

go: downloading github.com/cloudwego/netpoll v0.5.0
?       github.com/cloudwego/hertz/pkg/route/consts     [no test files]
?       github.com/cloudwego/hertz/pkg/route/param      [no test files]
# 只相差百分之0.2
ok      github.com/cloudwego/hertz/pkg/route    2.732s  coverage: 84.8% of statements
baize@baizedeMacBook-Air route %

单元测试：单测文件以 xx_test.go 命名，通过调用 xx.go 当中的方法，与一个预定义的值进行 assert 断言，相同则通过测试，补充单元测试直到满足85%的阈值，我们就可以着手提交 pr 了！

func TestConnectionClose(t *testing.T) {engine := NewEngine(config.NewOptions(nil))atomic.StoreUint32(&engine.status, statusRunning)engine.Init()engine.GET("/foo", func(c context.Context, ctx *app.RequestContext) {ctx.String(consts.StatusOK, "ok")})conn := mock.NewConn("GET /foo HTTP/1.1\r\nHost: google.com\r\nConnection: close\r\n\r\n")err := engine.Serve(context.Background(), conn)assert.True(t, errors.Is(err, errs.ErrShortConnection))
}

2.4 编码以及提交流程

2.4.1 编码前须知

一般来说，开源项目的根路径下，都有一个 CONTRIBUTING.md 文档，指导你如何参与本仓库的贡献，包括 git 使用的流程、单测覆盖率、代码的格式化等需求，参与任何开源，都建议先阅读这个文档。以 Hertz 为例：

2.4.2 仓库克隆流程

《一文搞懂Git工作流，再也不用担心入职就被辞退了》这篇文章是两年前我写作的，对 Git 工作流不甚了解的同学可以快速浏览。

🌟 针对开源项目，一般都选择 fork 仓库的形式进行开发：

将开源仓库 fork 到自己的 remote hertz。
在自己本地克隆自己的 remote hertz。

从本地的 develop 分支（或者 main 分支），切换一个新的 feature 分支出来，针对你要开发的内容，比如要增加 /pkg/router 的单测，则执行命令：

# 分支命名没有绝对约束，但是希望见名知意
checkout -b test_pkg_router

开发完成之后，将本地 test_pkg_router 分支代码，提交到自己的 remote hertz 的 test_pkg_router 分支。
- ⚠️注意：开发完成之后，不要急着提交，一般需要按照 CONTRIBUTING.md 的要求运行指定控制台命令进行单测运行与代码格式化等操作，确定没有问题后才能提交。
在自己的 remote hertz 仓库内，创建一个 pull request，将自己 remote hertz 仓库的 test_pkg_router 分支请求合并到 Hertz 官方仓库的开发分支上。提交 pr 的时候，需要描述自己的工作内容，以便 reviewers 快速明白你的意图，举个例子：

提交 pr 之后，一般都会触发 .github/workflows 目录下的各种 CI 流程，只有全部通过之后，reviewers 才能同意合入代码（code lint、test 等操作在这里也会执行，所以本地提前执行一次是未雨绸缪）：

2.5 后续提升

参与开源过程中，一般都有社群，找到志同道合的团体，一起交流，会让你事半功倍。

三、Gitea 的实习

3.1 Gitea 介绍

Gitea 是一个轻量级的、自助的 Git 服务。它是一个开源的、基于 Go 语言的项目，提供了类似于 GitHub、GitLab 等平台的版本控制仓库管理功能。

Gitea 允许您在自己的服务器上架设一个 Git 服务，以便团队或个人能够方便地进行代码托管、协作和版本控制。（GitHub 🌟 Star 40k+）

它的社区活跃度也非常高。

3.2 在 Gitea 的生活

🌟 面试：面试 Gitea 用了一轮面试，大概90分钟。面试官是一位字节架构出来的大哥。整个面试流程体验十分特殊：面试官开了屏幕共享，在自己的白板上写出各种 Go 语言相关的语法题目，涉及切片、map、interface{} 等 Go 的语法知识。询问十分细致，但不故意刁难。因为是做开源，相对项目经历反倒问的比较少。但是要求基础扎实，对 Go 的理解较为清晰。
🌟 工作内容：
- 看 issue，提 pr，和自主发电相比，实习是有工资的。
- 去实习之前很难想象在一家 GitHub star 数破40k的项目实习，是什么样的体验。去了之后发现，和在家没什么太大区别。不过有问题可以问身边的同事，但是平时解决问题都是个人为主。公司内人员极其精简，都是大牛，比较忙，除了分配一些工作，不太会主动找你。（所以架构部门真的很难进）
- 开发任务更多时候需要自己发掘，总结来说就是自由，甚至有些盲目。
🌟 体会：
- 在这里提升可能没有自己想象的那么快（但也绝对颇有收获），因为更多时候需要自己学习，而且因为是开源项目，对项目的熟悉也是慢慢来的，mentor 基本是没有时间指点你，除非你主动提问。（这与以业务为出发点的项目迭代是有所不同的，你甚至没有 kpi 推着你走）。
- 公司内管理层是圈内知名的开源大佬，在 Gitea 官方群内时刻与群友交流，解答各种问题。这也是我见过最身体力行的 Leader，做技术真的很纯粹，很佩服。