怎样做选择
- 选择你的第一个issues
一旦你选择好了一个开源项目,你需要找到一种开始的方式。
有时候,你会对一些需要改变的问题有强烈的的看法。其他时候,你可能只是希望帮助团队解决一个炙手可热的 issue。
如果您所做的不是修复一个单词错误或让demo正确编译,那么确实应该在他们的GitHub项目中为您将要进行的工作创建一个 issue。
提issue的好处:这可以确保您的工作是需要的,并且存储库所有者可以在您为这个主题花时间实现之前对其实现进行评论。
如果您不知道要处理什么,请转到代码仓库的 Issue 选项卡,查看所有可用的标记(tags)。想要查看当前开放的问题,找一些对你来说,看起来相对容易的一些标签,进行初步筛选。
现在,您需要找到一个问题,什么样的问题:对新接触存储库的人来说很容易完成。你感兴趣的内容,并且是对新接触存储库的人来说很容易完成的内容。
- 理解issue
当你发现一个问题时,你要仔细阅读他的描述和每一条评论。项目的作者和问题提出者在某种程度上已经加入进来了,出于对他们代码的尊重,您应该了解问题以及其解决方式的意图和关注点。
实际操作方法
- fork和clone仓库
虽然可以在本地clone代码仓库,但是没有fork意味着你不能进行 pull request操作
只需要点击GitHub上的fork按钮,他就会引导你fork一份仓库副本。
存储库fork之后,按照GitHub的提示,将fork的仓库clone到你的本地(GitKraken 或者 Sourcetree 都是很好的项目管理工具)。
- 了解团队的工作流程
下一步将根据项目和团队的不同而有所不同。首先,您需要确定应该基于哪个分支进行更改。接下来,您需要了解团队是否选择并专门化了 Git 工作流以及其分支的命名约定。
值得庆幸的是,在大多数存储库中你都不需要感到疑惑,因为社区已经规范了对于 contributing.md 和 readme.md 文件的创建, 它将指导您如何开始使用存储库,包括分支结构和 Git 工作流。也就是 贡献指南。
如果没有相关的文档就要小心了,因为团队可能不欢迎新的贡献者。
文档团队提供了一个非常有用的贡献指南,但是您可能不知道。您可能需要通过查看过去的提交来推断事情,以确定模式,甚至亲自联系存储库所有者。
在开始使用编辑器之前,我建议在 git 中根据适当的开始分支创建一个分支(参见前面的讨论)。一定要检查之前的分支,以及 contributing.md 和 readme.md 文档中关于分支命名的描述。
分支名称并不是没有意义的,因为稍后您将向另一个存储库提交 pull request,使用一致的分支名称会帮助你提升归属感。
- 自我定位
好了,现在您已经在本地获取了代码,您可以在任何编辑器中打开项目,以便处理需求。
您不太可能与像Microsoft文档团队这样优秀的团队一起工作(如果您这样做,我相信他们会很乐意听到他们可以改进的地方)。
即使有了这些readme的指导,你仍需要以你自己的方式来理解项目结构。而 contributing.md 可能有助于理解某些文件夹,通常我在项目中的第一步就是打开文件夹和子文件夹,直到我开始看到重复的组织模式。
一旦我熟悉了项目结构,我就开始寻找与我将要更改的代码相关的文件。
- 做出修改并测试
一旦你有了正确的答案,你需要做必要的修正或增强,测试它,然后提交修改后的文件。
构建代码、运行测试、运行 linters (如果适用的话),以及其他方式验证您的代码都是非常重要的,这是在更大的社区中,成为一个负责任的软件工程师的非常重要部分。
值得庆幸的是,大多数大型项目都在提交请求过程中内置了自动检查,这将确保您的代码符合团队标准,但是在创建 pull request 之前,确保您的代码在本地能够正常工作,这就避免了一些麻烦。
一旦提交了代码,请确保将其推送到了存储库的 forked 版本。为了创建 pull request ,这一步是必要的。
- 创建你的 Pull Request
现在,你已经推送了你的更改,你可以回到你的 forked 仓库 ,并通过点击适当的提示来创建 pull request。
现在您已经设定了目标,接下来按照团队的约定为您的请求命名。在我的示例中,我将提交的描述性标题和问题编号放在括号中。
团队还使用模板自动填充 pull request 主体的内容,我使用 markdown 语法编写了一个详细的更改列表。
如果您对将什么放入正在处理的存储库的 pull request 有任何顾虑,请花一些时间查看过去的 pull request 、它们的内容以及关于这些请求的任何注释。
准备好之后,单击 Create pull request。
接下来会发生什么?
祝贺您,您为开源软件社区做出了一点贡献。然而,这一旅程并没有结束。
您的代码可能需要通过自动检查(通常是一个构建,也可能是一些代码分析),然后才能进行评审。此外,项目维护者将需要检查您的更改,并通过将它们合并到源存储库中来选择是否接受它们。
在我的情况下,更改在第二天早上进行了审核,我收到了一条友好的消息和一个通知,我的 pull request 被接受了,问题也解决了。