标签 PR 下的文章

体验为开源做出贡献的快乐。

难以用言语形容我在收到合并通知(如下图)时的喜悦,当然这要归功于现在我上的工程学校 AltSchool Africa

successful merge message

在此之前,我曾多次接触过开源的概念,了解了它在技术领域的重要性,甚至参加过开源会议(比如 OSCAFest)。我曾多次跃跃欲试,但当打开 GitHub 来想创建些东西时,冒名顶替综合症就会冒出来。

时间来到 2022 年 8 月 8 日星期一,当观看了 Bolaji 为开源做贡献的视频之后,我重新振奋起来。不过,想要把我学到的东西付诸实践,我注意到需要下面几个步骤:

步骤:

  1. 我要下定决心,做好为一个开源项目做出贡献的心理建设。
  2. 我要根据我的技能水平进行筛选,我从一个站点(Good First Issues)寻找我开始的第一个项目。我不停地往下翻看,直到找到了一个符合心意的项目。
  3. 我要确定自己掌握完成项目所需的 Git 和 GitHub 知识。

LCTT 译注:

Good First Issues” 这个网站主要是针对那些想为开源软件做贡献,但不知道从哪里开始或如何开始的开发者。通过为开发者提供过滤器,该网站使他们能够根据自己熟悉的编程语言来浏览和选择问题和存储库。此外,他们还可以选择他们想要解决的问题的类型。

项目

经过长时间查找,我终于找到了一个名为 确保没有缺失的 alt 属性 的项目。我所要做的,就是为网站上的图片提供描述性的 alt 值。图片的 alt 值有助于提高网站的辅助功能,这样屏幕阅读器就可以向视障人士提供图像的详细描述了。这很简单,对吧?是的,但假如我没有下定决心想要作出贡献,我就不会找到这项目,在我心中开源仍将是个神话。

我心潮澎湃,直到发现这个项目是来自 MDN 的。等等, MDN Mozzila 开发者网络 ?干和 Mozilla 的开发者一样的事儿?他们会合并我这么小儿科的贡献吗?冒名顶替综合症 又开始了。

在检查这个议题时,我看到有人已经在提交贡献了,于是我鼓起勇气开始翻阅项目的内容。阅读和理解这个项目颇花费了我一些时间,而另一个要克服的,就是清楚处理这个议题我要怎么做。

这个项目就像你想的那么简单。

于是,我挑选了两幅图片着手尝试。我给它们的 alt 属性赋值,提交我的更改,然后发出拉取请求。从提交请求到收到批准邮件的这段时间,我充满了自我怀疑。我要不要关闭拉取请求?这可是 MDN 啊。好吧,这甚至都不算编程…… 如果请求没有被合并怎么办?我恐怕再也不会想为开源做出贡献了。不过,所有的疑虑都在我看到审阅者发来的这些邮件时烟消云散:

拉取请求确认邮件

拉取请求被合并的通知邮件

做出贡献和请求被合并的祝贺邮件

我喜出望外,这激发了我去检查更多图片的热情,也给了我发请求解决其他议题所需的勇气。

议题分配邮件

总结

我希望你能从这篇文章中感受到以下几点:

  • 开源是面向所有人的。你在刚刚访问的那个网站上看到拼写错误了吗?你帮助订正了拼写错误,这就是为开源做出了贡献。
  • 没有任何技能是微不足道的。如你所见,我所做出的贡献,只需要对 HTML 最基本的了解。
  • 能阻止你做出贡献的只有你自己。
  • 要想让雪球滚起来,需要做的就只是提交第一个贡献。

我衷心希望你能从我的经历中获得什么,并且今天就付诸实践。这也就是我想贡献的另一个领域,那么,我们下一篇文章见,也祝你开源愉快!

这篇文章最初发布于 我的第一个拉取请求被合并,并经许可转载。


via: https://opensource.com/article/22/9/first-pull-request-merged

作者:Oluwaseun 选题:lkxed 译者:onionstalgia 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

学习如何复刻一个仓库,进行更改,并要求维护人员审查并合并它。

你知道如何使用 git 了,你有一个 GitHub 仓库并且可以向它推送。这一切都很好。但是你如何为他人的 GitHub 项目做出贡献? 这是我在学习 git 和 GitHub 之后想知道的。在本文中,我将解释如何 复刻 fork 一个 git 仓库、进行更改并提交一个 拉取请求 pull request

当你想要在一个 GitHub 项目上工作时,第一步是复刻一个仓库。

 title=

你可以使用我的演示仓库试一试。

当你在这个页面时,单击右上角的 “Fork”(复刻)按钮。这将在你的 GitHub 用户账户下创建我的演示仓库的一个新副本,其 URL 如下:

https://github.com/<你的用户名>/demo

这个副本包含了原始仓库中的所有代码、分支和提交。

接下来,打开你计算机上的终端并运行命令来 克隆 clone 仓库:

git clone https://github.com/<你的用户名>/demo

一旦仓库被克隆后,你需要做两件事:

1、通过发出命令创建一个新分支 new_branch

git checkout -b new_branch

2、使用以下命令为上游仓库创建一个新的 远程 remote

git remote add upstream https://github.com/kedark3/demo

在这种情况下,“上游仓库”指的是你创建复刻来自的原始仓库。

现在你可以更改代码了。以下代码创建一个新分支,进行任意更改,并将其推送到 new_branch 分支:

$ git checkout -b new_branch
Switched to a new branch ‘new_branch’
$ echo “some test file” &gt; test
$ cat test
Some test file
$ git status
On branch new_branch
No commits yet
Untracked files:
  (use "git add &lt;file&gt;..." to include in what will be committed)
    test
nothing added to commit but untracked files present (use "git add" to track)
$ git add test
$ git commit -S -m "Adding a test file to new_branch"
[new_branch (root-commit) 4265ec8] Adding a test file to new_branch
 1 file changed, 1 insertion(+)
 create mode 100644 test
$ git push -u origin new_branch
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 918 bytes | 918.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
Remote: Create a pull request for ‘new_branch’ on GitHub by visiting:
Remote:   <http://github.com/example/Demo/pull/new/new\_branch>
Remote:
 * [new branch]         new_branch -&gt; new_branch

一旦你将更改推送到您的仓库后, “Compare & pull request”(比较和拉取请求)按钮将出现在GitHub。

 title=

单击它,你将进入此屏幕:

 title=

单击 “Create pull request”(创建拉取请求)按钮打开一个拉取请求。这将允许仓库的维护者们审查你的贡献。然后,如果你的贡献是没问题的,他们可以合并它,或者他们可能会要求你做一些改变。

精简版

总之,如果您想为一个项目做出贡献,最简单的方法是:

  1. 找到您想要贡献的项目
  2. 复刻它
  3. 将其克隆到你的本地系统
  4. 建立一个新的分支
  5. 进行你的更改
  6. 将其推送回你的仓库
  7. 单击 “Compare & pull request”(比较和拉取请求)按钮
  8. 单击 “Create pull request”(创建拉取请求)以打开一个新的拉取请求

如果审阅者要求更改,请重复步骤 5 和 6,为你的拉取请求添加更多提交。

快乐编码!


via: https://opensource.com/article/19/7/create-pull-request-github

作者:Kedar Vijay Kulkarni 选题:lujun9972 译者:furrybear 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

通过使用 GitHub 的 拉取请求 Pull Request 正确地进行代码审核,把时间更多的花在构建上,而在修复上少用点时间。

Measure

如果你不是每天编写代码,你可能不知道软件开发人员日常面临的一些问题。

  • 代码中的安全漏洞
  • 导致应用程序崩溃的代码
  • 被称作 “技术债务” 和之后需要重写的代码
  • 在某处你所不知道地方的代码已经被重写

代码审查 Code review 可以允许其他的人或工具来检查代码,帮助我们改善所编写的软件。这种审查(也称为 同行评审 peer review )能够通过自动化代码分析或者测试覆盖工具来进行,是软件开发过程中两个重要的部分,它能够节省数小时的手工工作。同行评审是开发人员审查彼此工作的一个过程。在软件开发的过程中,速度和紧迫性是两个经常提及的问题。如果你没有尽快的发布,你的竞争对手可能会率先发布新功能。如果你不能够经常发布新的版本,你的用户可能会怀疑您是否仍然关心改进你的应用程序。

权衡时间:代码审查与缺陷修复

如果有人能够以最小争议的方式汇集多种类型的代码审查,那么随着时间的推移,该软件的质量将会得到改善。如果认为引入新的工具或流程最先导致的不是延迟,那未免太天真了。但是代价更高昂的是:修复生产环境中的错误花费的时间,或者在放到生产环境之前改进软件所花费的时间。即使新工具延迟了新功能的发布和得到客户欣赏的时间,但随着软件开发人员提高自己的技能,该延迟会缩短,软件开发周期将会回升到以前的水平,而同时缺陷将会减少。

通过代码审查实现提升代码质量目标的关键之一就是使用一个足够灵活的平台,允许软件开发人员快速编写代码,置入他们熟悉的工具,并对彼此进行同行评审。 GitHub 就是这样的平台的一个很好的例子。然而,只是把你的代码放在 GitHub 上并不会魔术般地使代码审查发生;你必须使用 拉取请求 Pull Request 来开始这个美妙的旅程。

拉取请求:关于代码的现场讨论

拉取请求 Pull Request 是 Github 上的一个工具,允许软件开发人员讨论并提出对项目的主要代码库的更改,这些更改稍后可以部署给所有用户看到。这个功能创建于 2008 年 2 月,其目的是在接受(合并)之前,对某人的建议进行更改,然后在部署到生产环境中,供最终用户看到这种变化。

拉取请求开始是以一种松散的方式让你为某人的项目提供更改,但是它们已经演变成:

  • 关于你想要合并的代码的现场讨论
  • 提升了所更改内容的可视功能
  • 整合了你最喜爱的工具
  • 作为受保护的分支工作流程的一部分可能需要显式的拉取请求评审

对于代码:URL 是永久的

看看上述的前两个点,拉取请求促成了一个正在进行的代码讨论,使代码变更可以更醒目,并且使您很容易在审查的过程中找到所需的代码。无论是对于新人还是有经验的开发人员,能够回顾以前的讨论,了解一个功能为什么以这种方式开发出来,或者与另一个相关功能的讨论相联系起来是无价的。当跨多个项目协调,并使每个人尽可能接近代码时,前后讨论的内容也非常重要。如果这些功能仍在开发中,重要的是能够看到上次审查以来更改了哪些内容。毕竟,审查小的更改要比大的容易得多,但不可能全都是小功能。因此,重要的是能够找到你上次审查,并只看到从那时以来的变化。

集成工具:软件开发人员的偏执

再看下上述第三点,GitHub 上的拉取请求有很多功能,但开发人员总是偏好第三方工具。代码质量是个完整的代码审查领域,它涉及到其它组件的代码评审,而这些评审不一定是由人完成的。检测“低效”或缓慢的代码、具有潜在安全漏洞或不符合公司标准的代码是留给自动化工具的任务。类似 SonarQubeCode Climatecan 这样工具可以分析你的代码,而像 CodecovCoveralls 的这样工具可以告诉你刚刚写的新代码还没有得到很好的测试。这些工具最令人称奇的是,它们可以集成到 GitHub 中,并把它们的发现汇报到拉取请求当中!这意味着该过程中不仅是人们在审查代码,而且工具也在会在那里报告情况。这样每个人都可以完全了解一个功能是如何开发的。

最后,根据您的团队的偏好,您可以利用受保护的分支工作流 必需状态 required status 功能来要求进行工具审查和同行评审。

虽然您可能只是刚刚开始您的软件开发之旅,或者是一位希望知道项目正在做什么的业务利益相关者,抑或是一位想要确保项目的及时性和质量的项目经理,你都可以通过设置批准流程来参与到拉取请求中,并考虑集成更多的工具以确保质量,这在任何级别的软件开发中都很重要。

无论是为您的个人网站,贵公司的在线商店,还是想用最新的组合以获得最大的收获,编写好的软件都需要进行良好的代码审查。良好的代码审查涉及到正确的工具和平台。要了解有关 GitHub 和软件开发过程的更多信息,请参阅 O'Reilly 的 《GitHub 简介》 一书, 您可以在其中了解创建项目、启动拉取请求以及概要了解团队的软件开发流程。


作者简介:

Brent Beer

Brent Beer 通过大学的课程、对开源项目的贡献,以及担任专业网站开发人员使用 Git 和 GitHub 已经超过五年了。在担任 GitHub 上的培训师时,他也成为 O’Reilly 的 《GitHub 简介》的出版作者。他在阿姆斯特丹担任 GitHub 的解决方案工程师,帮助 Git 和 GitHub 向世界各地的开发人员提供服务。

Peter Bell

Peter Bell 是 Ronin 实验室的创始人以及 CTO。培训是存在问题的,我们通过技术提升培训来改进它!他是一位有经验的企业家、技术专家、敏捷教练和 CTO,专门从事 EdTech 项目。他为 O'Reilly 撰写了 《GitHub 简介》,为代码学校创建了“精通 GitHub ”课程,为 Pearson 创建了“ Git 和 GitHub 现场课”课程。他经常在国际和国际会议上发表 ruby、 nodejs、NoSQL(尤其是 MongoDB 和 neo4j )、云计算、软件工艺、java、groovy、j 等的演讲。


via: https://www.oreilly.com/ideas/how-to-use-pull-requests-to-improve-your-code-reviews

作者:Brent Beer, Peter Bell 译者:MonkeyDEcho 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出