Funky's NoteBook

How to contribute to open source projects

字数统计: 1,904阅读时长: 7 min
2018/08/24 Share

如何贡献开源项目

最近看见很多同学遇到这个问题,今天总结下为热爱开源社区并愿意为开源项目贡献的同学提供思路。

那么下面我们简单的聊聊如何贡献开源项目。

贡献之前

了解项目

在贡献开源项目之前首先你要了解你想要贡献的开源项目,这是必须的,不然容易闹出意想不到的笑话,GitHub本身也是个国际交流的平台,我们作为国人也要谨言慎行,维护我们的良好形象。很多高质量的大项目都有他们的贡献注意事项,一定要仔细查看,特别是当你贡献文档类型的项目时,一定要注意文档的约定和术语表的使用以及格式段落用法。

提高自己的英语水平

在 Github 上面,无论是和外国人还是中国人交流,统一使用英语。除非你明确知道这个项目是中国人做的,并且你已经在历史的 issue 与 Merge 里看见了使用中文交流的案例,但是仍然不建议。虽然目前在线翻译如谷歌翻译的翻译能力已经十分的强悍,但是依旧免不了一些细微的人工调整让语句变得更加通顺。在线翻译是一个十分有利的工具,但并不是救命稻草,所有依赖在线翻译是并不现实的事情,因此还是要提升自己的英语水平,扩大词汇量、语法知识和专业词汇。

学会使用Git

Git 是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。它本身是伟大的Linux 创始人 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件,它有以下优点:

  • 适合分布式开发,强调个体。

  • 公共服务器压力和数据量都不会太大。

  • 速度快、灵活。

  • 任意两个开发者之间可以很容易的解决冲突。

  • 离线工作。

Git 也是大部分程序员必须会使用的工具,大部分企业或是厂商都使用 Git 作为他们软件或是项目的版本控制工具,因此学会使用它十分必要。

廖雪峰的 Git 学习笔记:https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

GitHub 与 Git

GitHub 顾名思义,Git的Hub,一个面向开源及私有软件项目的托管平台,只支持 git 作为唯一的版本库格式进行托管,但是他本身与Git项目并没有太大的关系。

历年也有很多不正确的使用闹出很多笑话的例子,各位在使用上一定要谨慎!

这里也插一句嘴,Git 学习只需要学那些用的比较多的命令,有些命令可能你一辈子都不会用到。既然 Git 是一个工具,就没必要把时间浪费在那些“高级”但几乎永远不会用到的命令上。一旦你真的非用不可了,到时候再自行 Google 或者请教专家也未迟。

学会使用 Markdown

Markdown 是一种可以使用普通文本编辑器编写的标记语言,通过简单的标记语法,它可以使普通文本内容具有一定的格式。 它的语法简洁明了、学习容易,而且功能比纯文本更强,因此有很多人用它写博客。在开源项目中,我们经常使用 Markdown 写项目的 readme.md 或是项目的文档,使用 Markdown 编写的文章可以通过工具快速渲染为 HTML 网页或 PDF 文档,因此使用起来非常方便,它也被称为迷你 HTML 、 小 HTML,我们可以使用 Typoravscode 等工具编写。目前,各大博客网站、简书、知乎等已经支持了 Markdown撰写文章的功能,掌握这门技术必定可以为你的项目增光添彩。

GitHub 官方 Markdown 入门: https://guides.github.com/features/mastering-markdown/

贡献的类型

我把在 Github 贡献的类型分为两类:

  • 通过提 issue 贡献
  • 通过 Pull Request 贡献

这两种也是 GitHub 最为常用的两种贡献方式,下面我们就分别具体讲讲如何通过这两种情况实现项目贡献。

通过提 issue 贡献

提 issue 也就是问问题,使用这种方法通常有两种情况,第一种在使用中遇到了问题,出了错误,或是有不懂的地方,你可以通过提 issue 与开发者交流问题,你需要标记你的 issue Label 为 Question;第二种是是遇到了问题发现了代码的Bug,并且你十分的确定这就是bug,但是你不知道怎么修复,你需要标记你的 issue Label 为 bug 或是 error,这里先讲讲提 issue 的规范:

issue 的标题最好是英文,这应该算是 Github不成文的约定。

在提 issue 时一定要具体描述你出现的问题,你整个过程执行了哪些命令,报了什么错误,出现了什么问题,你尝试执行了哪些命令或是措施等等。

最好完整贴上你执行的步骤代码、报错截图、你当前使用的操作系统版本、运行环境版本、开发语言版本、第三方库的版本越全越好,让开发者更加容易定位到你的问题,并指导你解决问题。

通过 Pull Request 贡献

使用 Pull Request 贡献项目主要针对遇到了问题发现了代码的 bug,并且你十分的确定这就是bug,同时你定位到了错误的位置,你也知道怎么去修复。这对这种情况,我下面说说整个贡献的流程:

  1. 先到他的项目地址 fork 它的项目到你自己的仓库。
  2. clone 你 fork 过来的仓库到你的本地计算机。
  3. 在你的本地修改 bug。
  4. commit 你修改的代码。
  5. 提交到你的远程 fork 过来的仓库。
  6. 申请 Pull Request。

申请 Pull Request 的时候也要注意下面几点:

  • 标题依旧使用英文,并写上你主要做的事情,如:Fix xxx errors、Update xxx等。
  • 描述可以完整的写一下你主要做的工作,修复了什么问题,改了那些地方,想达到什么样的效果等
  • 注意 Maintainer 的留言,你的代码可能还需要加以修改。
  • 注意项目的 CI 进展

有的大项目自带了 CI 的功能,当你申请了 PR 时他会自动触发并编译你的代码,如果 CI 不通过一定要查看 CI 的报错信息并加以修改或是联系 Maintainer 咨询解决方案。

如果你的 Pull Request 还需要修改,那么我的建议是,你在本地计算机修改后,commit后 push 到你申请 PR 的分支上就可以实现更新了,并且一定要关注再次 CI 构建的结果。

还有一个建议,如果你发现了很多地方需要 Merge,那么请你本地创建多个多个 branch 分别 Merge,以免出现一个 PR 多个 bug 或是 file change 的情况。

祝愿你在贡献开源项目的道路上越走越远,并成为一名优秀的开源贡献者!

CATALOG
  1. 1. 如何贡献开源项目
    1. 1.1. 贡献之前
      1. 1.1.1. 了解项目
      2. 1.1.2. 提高自己的英语水平
      3. 1.1.3. 学会使用Git
        1. 1.1.3.1. GitHub 与 Git
      4. 1.1.4. 学会使用 Markdown
    2. 1.2. 贡献的类型
    3. 1.3. 通过提 issue 贡献
    4. 1.4. 通过 Pull Request 贡献