大学生如何在开源贡献中投资自我

内容纲要

大家好!很荣幸能够受邀在今晚的活动中,站在一名大学生的视角分享——如何通过开源受益、如何在开源贡献中投资自己,也希望有助于小伙伴参与OpenHarmony贡献者计划。那么,以下主要分为了三个小的主题,分别可以归纳为“如何开始”、“合理匹配”与“实际意义”,且听我一一展开:

1. 从没接触过开源项目,怎么参与OpenHarmony开源贡献

  • 首先,对于很多刚入门甚至还没入门的小伙伴来说,基本只是了解过或是简单用过github、gitee、bitbucket、gitlab这类的git平台,比如说要下一些特定场合的软件,它们多数是挂靠在这些托管平台上,我们只需要在README中按照指示点一点找到下载链接就可以了。至于说要专门用到git工具,如果不参与开源项目的实际开发,几乎没有必要。
  • 其次,我们还需要搞清楚什么是“开源项目”,因为git的诞生一定程度上就关联于它,可以说是互相绑定。“开源”这个词,圈内圈外人士一定都不陌生。从字面上理解——拆开的全称为“开放源代码”,意思就是源代码是公开的、能获取到的,同时软件又是免费的,然而仅仅停留在这一层面,就非常片面、单一了。真正要详解开源的所有相关内容,其实要说花上数几个小时都不为过,它还包含一些许可、精神、意义等,而非以上所述如此简单。
  • 那开源跟git到底存在什么关系呢?git最初是linus为了更好地维护linux内核并替代bitkeeper而设计开发的这么一种版本控制系统,说白了其实就是为了更方便地发动世界所有对linux内核这样一个开源项目感兴趣的爱好者,通过共同修改源码进行共建,从而使项目变得更强大,这也是区别于闭源的优势。有了 git 后,我们就能实现想怎么玩就怎么玩,即便写太多 bug 把项目写死了,那回退一下就好了。
  • 接下来简单演示一下 git 的基本使用,以及如何提交PR参与OpenHarmony开源贡献。虽然相关的教程网络上比较多,但我还是以在校大学生的经验过一下流程吧,背后的具体原理大家可以寻求gitee文档或bilibili。
  1. 环境配置
    file
    file
    file
    file
    file
    file
    此时环境差不多就配置好了,下面演示两种方式修改源码+提PR。

  2. 修改源码

    1. 方式一:拉取至本地修改
      file
      file
      file
      file
      file
      file
      file
      本地推送的时候也可以用 IDE 插件,这里不演示了,继续PR提交部分。所谓 PR,即 Pull Request,就是申请把自己的修改并入原仓的操作。不过正常流程来说,是要关联相应的 issue 的,由于演示所以忽略这一步。
      file
      file
      file
      file

    2. 方式二:Gitee 在线 IDE 修改
      file
      file
      file
      file
      实际上,方式二演示的过程同样可以方式一fork后再进行,这样就能直接创建新分支PR,不用再一次修改PR说明。

2. 技术能力一般,一样可以提交PR

  • 首先,这个问题我觉得不是问题,OpenHarmony 截止目前一共有 412 个仓,这些仓中并不全是代码,也有以文字为主体的,比如说比较火热的 docs 仓,主要是为了帮助开发者迅速了解 OpenHarmony。我们只需要稍微懂点 markdown 格式的语法,就可以尝试在docs仓修正提交 PR,为 OpenHarmony 出微薄的一份力。
  • 同时,纯文字分析起来较快,能够轻易定位错误。如果技术能力较好,就可以逛一逛其他仓比如说 HDF 等,根据 issue 提出的问题作出相应的更正。所以提交这块,见仁见智了,技术上可以跟随 OpenHarmony 社区学习就会慢慢提高,或者社群里提问,也会有很多热心的老师及同学朋友提出指导建议。任何一名开发者都是 OpenHarmony 要汇聚的星星之火,星星之火可以燎原。
  • 还有就是,提交 PR 的标准建议是每个 PR 只对应一次提交,如果对应多次提交,可能会造成版本错乱,从而带来一些不必要的麻烦。提交之后,也需要时不时返回 Gitee 主页的 Pull Request 子页面关注进展,比如说 commiter 的回复、构建报错、代码冲突、提交超时等等一系列问题,需要及时处理,有明显问题无法解决的应把 PR 关闭,提高整个社区的处理效率。

3. 为什么要把开源当作一种生活习惯

  • 最后一项主题是“为什么要把开源当作一种生活习惯”。从一名大学生的角度看来,我是这样理解的:我们开源多半会把代码挂靠在 git 平台上,这些平台多数都会有这样一种代码贡献墙,我截了一张 linus 的样式作为示例:
    file

  • 从上图中我们可以看到,linus 一整年内一共进行了 2530 次提交,颜色深浅不同的块即代表了每一天贡献的强度,所以不用多说,自然是非常厉害了。所以说,账号首页一定程度上象征着一名程序员的缩影,见证了我们的成长史。当然也不是那么绝对,因为不是随便写点东西都必须要放到云端,有的人可能就没有这种习惯也无所谓,只会觉得麻烦。但有总比没有好,因为面试一些企业时,HR 可能就会对个人的 Git 账号比较感兴趣,如果你的代码墙很亮眼的话,加上有很多特别有意义或是技术含量的项目,那么这个优势就会显而易见了。

  • 其次,当你每次提交 PR 或推送时,都会有很强烈的成就感,会引导着内心继续补充下一次提交。那么,即便单纯地写代码会觉得枯燥,在这样一种场景下,也会变得不枯燥了。久而久之,便养成了这样一种日常工作的方式与良好习惯,我们自身的技术实力自然也会受益于其,跟着迅速地提高。综上,这何尝不是一笔巨大的财富、一种对自身的投资呢?

  • 开源能更好地服务于世界技术的发展,也是广大技术人信奉的宗旨。就像 OpenHarmony 一样,开源能够帮助其飞速地成长、变得强大,这也是我们所有人一直在努力着的。那么最后,感谢社区提供的本次直播分享机会,也感谢众多 Committer 的辛苦付出,希望有限的篇幅能对各位观众读者有所帮助~


1、大学生/萌新小白,如何参与到开源项目的实际开发?

  • 我觉得不管什么身份什么能力,只要能够推着某一个开源项目前进这么一丢丢距离都很珍贵。每个人都是从小白过来的,当我们也处于这个阶段时,肯定是无法做出什么特别大的贡献,这需要一点一滴地积累。积累的过程实际上就是我们在不断学习的过程,根本上还是为了以后能够做大型开发而所作的铺垫,只是现阶段可能实现不了而已。对应于自己的实际情况,哪怕只提非常简单的一个 PR 或参与社区的相关活动,都算是在项目发展中留了名、参与进了实际开发。

2、提交PR时,显示dco协议检查失败是什么原因?如何解决?

  • 这个问题在dco协议已经签署的情况下,多半是信息没有填对或没有正确绑定到commit上。署名格式就是 "Signed-off-by: gitee_id xxx@xxx",可返回已提 PR 页面的子页面检查署名信息。如果错误,可以返回个人仓库分支重新提交 commit 信息后再返回PR页面尝试评论"check dco"触发检查;不过,建议关闭PR重新再开一个。其次,避免使用 "git commit -s",只推荐使用 "git commit --amend --signoff" 取代原始提交进行署名。

3、一般什么情况下选择提轻量级PR?

  • 轻量级 PR,顾名思义,就是轻量,无需涉及具体环境。譬如身旁没有电脑只有手机时,或者,只进行一些简单的修改不需要用到专门的测试工具时,就可以使用轻量PR。

4、除了docs仓,还有其他推荐系统或代码仓比较火热?

  • 除了docs仓,大家还可以去看看ArkUI、媒体、测试、驱动等其他系统,这些也是开发者比较多去看的领域。

留下评论

您的电子邮箱地址不会被公开。