实战模拟│程序员应该学会的开源共建

Posted 2022-11-11 极客飞兔

✨ 目录

• • 🎈 参与开源项目的必要性
  • 🎈 寻找合适的开源项目
  • 🎈 寻找项目问题 / issues
  • 🎈 提出申请
  • 🎈 Fork 开源项目
  • 🎈 拉取项目到本地
  • 🎈 开始自己的表演
  • 🎈 Push 代码
  • 🎈 创建 PR 并入上游

🎈 参与开源项目的必要性

• 相信很多程序猿小白在自己的职业生涯中都本着 拿来即用 的特质
• 对于 项目开源 都是 只闻其概念，不见其本质，大多数人都只停留在 观望阶段，这也与国内的开源环境有关，阻止国内程序员参与开源的一个重要的原因不是 技术能力 的限制，而是 英语水平 的限制
• 阅读过某个开源项目源码的人很少，参加某个开源社区的人更少，更别说知道如何去参与开源项目 提 PR 了
• 但是参与开源项目对于程序猿是必修课，也是必须学会的一门技能，参与开源的最大好处就是贡献所得到的 成就感。更深刻熟练的运用自己的技能，也可以获得更好的 认可度和知名度，建立更 广大的人脉

🎈 寻找合适的开源项目

• 如果你决定参与开源开源项目，请记住：不要选择特别成熟的开源项目、不要选择小规模的开源项目、尽量选择知名开源软件基金会的孵化项目
• 如果项目太成熟，由于参与的人数太多，你的成就很容易被淹没，很容易打击自己的自尊心和参与感
• 如果项目太小，由于代码流程等各种不规范，你会变得束手束脚，会出现很多问题
• 而开源软件基金会的项目，基本会介于这两者之间，既不会显得太不成熟，也可以让你有很好的参与感，比如 Apache 基金会、Linux 基金会、CNCF 等。
• 你可以从 CNCF 沙箱项目 或者 Apache 项目 中找到适合自己的开源项目并参与其中

🎈 寻找项目问题 / issues

• 在每一个项目仓库中，都会有 issues 板块，这里标注了该项目中还存在的各种各样的 漏洞、文档完善、测试用例完善、bug 反馈 等等，等待着各位开源者一起去完善，共同将该项目的 issues 板块清空
• 我们这里以 envoyproxy/envoy 开源项目为例，在这里可以看到很多待处理的问题，并且每个问题后面标注了显眼的标签，比如 bug、triage、enhancement等等
• 点击其中任意的标签，就可以筛选所有带有相同标签的问题吗，方便用户搜索自己想解决的某一类问题，如果你专注于处理 bug 问题，可以点击 bug 标签，出来的全是 bug标签 的待解决问题了

🎈 提出申请

• 每一个开源项目中都会有 CONTRIBUTING.md 文件，这个文件会详细介绍如何开始当前的项目，感兴趣的可以自己去看看
• 当你浏览完 issues列表 后，找到一个自以为可以解决的问题，点进去可以查看详情
• 在浏览了这个 issues要求后，你觉得你可以解决的话，就可以给管理员留言
• 静静等待管理员通过审核，将该任务指派给你即可进行开发了

🎈 Fork 开源项目

• 首先在登录自己账号的状态下，fork 该仓库，将该仓库 fork 到自己的账号下
• 因为你想修改原始仓库里面的东西，必须要有修改的权限，把该仓库 fork 到自己的账号下，意味着你有修改仓库里面文件的权限了
• 其实 提交 PR 就是将你修改的内容推送到自己 fork 出来的代码中，然后再通过 Pull Request 将其合并入上游项目中即可

🎈 拉取项目到本地

• 首先我们需要将自己仓库中 fork 过来的项目，拉取到本地
• 当然拉取代码可以实用 SSH 方式，也可以实用 HTTPS 模式
• 本地的代码变更永远只提交到 origin，然后通过 origin 提交 Pull Request 到 upstream

# 拉取项目
git clone https://github.com/autofelix/envoy.git

# 进入项目目录
cd envoy

# 配置上游仓库
git remote add upstream https://github.com/envoyproxy/envoy.git
git remote set-url --push upstream no_push

# 配置完成后，查看是否正确
git remote -v

# 结果如下
origin    [e-mail]:autofelix/envoy.git (fetch)
origin    [e-mail]:autofelix/envoy.git (push)
upstream    https://github.com/envoyproxy/envoy (fetch)
upstream    no_push (push)

🎈 开始自己的表演

• 把项目拉到本地之后，你需要更新一下本地代码，让他保持跟上游 upstream 一致
• 这是为了防止后期出现各种冲突，让你头大，毕竟解决冲突在协同开发中是最费心费力的
• 当然，如果你只提交一个PR，可以直接在main 分支进行开发，但是当你爱上了开源，我相信你不会仅仅只会提交一个 PR，总之鼓励你通过创建分支去提交 PR，完成开源工作，会更加的规范

# 代码跟上游同步
git fetch upstream
git checkout main
git rebase upstream/main

🎈 Push 代码

• 首先如果你解决的是一个bug，我建议你创建 fix 分支 git checkout -b fix-xxx，如果是文档类更新可以创建 docs-xxx，其他建议创建 chore-xxx，不同类型的 issues 创建不同的分支，清晰明了
• 在修复好 bug 后，通过以下命令进行 push

git add <file>
git commit -s -m "some description here"
git push origin fix-xxx

🎈 创建 PR 并入上游

• 在 push 之后，打开 GitHub，可以看到一个提示框，系统告诉我们可以开一个 Pull Request 了
• 点击该按钮之后，会有一个回复的格式模板，我们只要按照模板去修改其中的一些内容即可，不同的开源项目 PR 回复模板一般不同
• 但是大体上都是需要填写你 这次PR的标题，修改了哪些地方，怎么测试的，解决了什么问题等等
• 提交了 PR 之后，我们就可以在 PR 列表里找到自己的 PR 了，不过需要注意的是 ci 检查 是不是全部能够通过，假如失败了，需要及时修复出错的修复，重新提交
• 当你做完了这些，只要你的 PR 很完美，不出很长时间，管理员就会直接将你的 PR 合并到项目中，那么这一次的开源生命周期到此也就结束了，你可以重新寻找新的 issues 去完成