开源一夏│别逗，作为程序员你竟还没参与过开源项目？

 参与开源项目的必要性

• 相信很多程序猿小白在自己的职业生涯中都本着 
  拿来即用
   的特质

• 对于 
  项目开源
   都是 
  只闻其概念，不见其本质
  ，大多数人都只停留在 
  观望阶段
  ，这也与国内的开源环境有关，阻止国内程序员参与开源的一个重要的原因不是 
  技术能力
   的限制，而是 
  英语水平
   的限制

• 阅读过某个开源项目源码的人很少，参加某个开源社区的人更少，更别说知道如何去参与开源项目 
  提 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
   模式，但是 
  github 
  现在好像不支持 
  HTTPS
   进行代码推送了

• 本地的代码变更永远只提交到 
  origin
  ，然后通过 
  origin
   提交 
  Pull Request
   到 
  upstream

 开始自己的表演

• 把项目拉到本地之后，你需要更新一下本地代码，让他保持跟上游 
  upstream
   一致

• 这是为了防止后期出现各种冲突，让你头大，毕竟解决冲突在协同开发中是最费心费力的

• 当然，如果你只提交一个
  PR
  ，可以直接在
  main
   分支进行开发，但是当你爱上了开源，我相信你不会仅仅只会提交一个 
  PR
  ，总之鼓励你通过创建分支去提交 
  PR
  ，完成开源工作，会更加的规范

 Push 代码

• 首先如果你解决的是一个
  bug
  ，我建议你创建 
  fix
   分支 
  git checkout -b fix-xxx
  ，如果是文档类更新可以创建 
  docs-xxx
  ，其他建议创建 
  chore-xxx
  ，不同类型的 
  issues 
  创建不同的分支，清晰明了 

• 在修复好 
  bug
   后，通过以下命令进行 
  push

 创建 PR 并入上游

• 在 
  push
   之后，打开 
  GitHub
  ，可以看到一个提示框，系统告诉我们可以开一个 
  Pull Request
   了

• 点击该按钮之后，会有一个回复的格式模板，我们只要按照模板去修改其中的一些内容即可，不同的开源项目 
  PR
   回复模板一般不同

• 但是大体上都是需要填写你 
  这次PR的标题
  ，
  修改了哪些地方
  ，
  怎么测试的
  ，
  解决了什么问题
  等等

• 提交了 
  PR
   之后，我们就可以在 
  PR
   列表里找到自己的 
  PR
   了，不过需要注意的是 
  ci 检查
   是不是全部能够通过，假如失败了，需要及时修复出错的修复，重新提交

• 当你做完了这些，只要你的 
  PR
   很完美，不出很长时间，管理员就会直接将你的 
  PR
   合并到项目中，那么这一次的开源生命周期到此也就结束了，你可以重新寻找新的 
  issues
   去完成