开源项目贡献知乎_以正确的方式为开源项目做贡献

最新推荐文章于 2024-08-09 07:04:06 发布

weixin_26712121

最新推荐文章于 2024-08-09 07:04:06 发布

阅读量653

点赞数

文章标签： java python 项目管理 linux

原文链接：https://medium.com/better-programming/contributing-to-open-source-projects-the-right-way-81a2e0d8ba3c

版权

开源项目贡献知乎

When I started with open source contributions in April 2019, I remember being scared about doing everything wrong. I didn’t want to mess up on a pull request and be branded as a noob, never able to taste the sweet success of getting an open source pull request reviewed and merged.

当我在2019年4月开始进行开源贡献时，我记得自己害怕做错任何事情。我不想弄乱一个请求请求而被打上菜鸟的烙印，也从来没有尝过对开源请求请求进行审查和合并的成功。

There were so many questions that I had to find answers to:

有太多问题，我不得不寻找答案：

What skills do I need to be able to contribute successfully?
我需要什么技能才能成功贡献？
How do I write commit messages correctly?
如何正确编写提交消息？
What is forking? What is upstream?
什么是分叉？上游是什么？

Although there were articles and tips and tricks available on the web, it was tedious to gather all the necessary information bit by bit.

尽管网上有文章，技巧和窍门，但是一点一点地收集所有必要的信息是很麻烦的。

After contributing to open source projects regularly for a while now and feeling comfortable with the workflow, I decided to share my knowledge with you so you don’t have to start from zero like I did.

在定期为开放源代码项目做出贡献并感到对工作流程感到满意之后，我决定与您分享我的知识，因此您不必像我一样从零开始。

Additionally, my motivation is to bring people who are hesitant to start with open source contributions to take the first step. More developers contributing to open source projects means better quality of code, more documentation written, and faster development speed, which is a benefit for all of us.

此外，我的动机是让犹豫不决的人们开始使用开源贡献，迈出第一步。更多的为开源项目做出贡献的开发人员意味着更高的代码质量，更多的文档编写以及更快的开发速度，这对我们所有人都是有益的。

为什么要为开源项目做贡献 (Why You Should Contribute to Open Source Projects)

Improve your coding skills. Working with different code bases is a great way of getting better at coding fast. Contrary to a work environment where you might work on one project for a longer period, with open source projects you can switch to another project whenever you want and get to know various tooling and setups.
提高您的编码技巧。 使用不同的代码库是快速提高编码效率的一种好方法。与您可能在一个项目上长期工作的工作环境相反，使用开源项目，您可以随时切换到另一个项目，并了解各种工具和设置。
Give back to the community. You are probably using a lot of different repositories daily for free, and this is your chance to contribute as a way of thanking the project.
回馈社区。 您可能每天免费使用许多不同的存储库，这是您感谢该项目的机会。
Improve your prestige. You will be easier to hire with merged pull requests for well-known projects, or you might even turn into a thought leader for a certain topic.
提高您的声望。 通过合并对知名项目的合并请求，您将更容易被雇用，或者您甚至可以成为某个主题的思想领袖。
Work with different teams. Each repository has different contributors and coding conventions that you will need to adapt to.
与不同的团队合作。 每个存储库都有不同的贡献者和您需要适应的编码约定。
Solve interesting problems. Finding solutions to complex problems can be fulfilling and a lot of fun. You are also able to choose which issues you want to work on.
解决有趣的问题。 找到解决复杂问题的方法可能会很有趣，而且很有趣。您还可以选择要处理的问题。

If you think that you don’t have enough experience to contribute to projects with code, don’t worry. You can always help out by improving documentation, answering issues, or with the internationalization of a project until you feel ready.

如果您认为您没有足够的经验来为使用代码的项目做贡献，请不要担心。在准备就绪之前，您总是可以通过改善文档，回答问题或项目的国际化来提供帮助。

我的一些贡献 (Some of My Contributions)

To give you a bit of an overview of projects that you could be working on, here are some open source contributions that I worked on:

为了让您大致了解可以从事的项目，以下是我从事的一些开源贡献：

sveltejs/svelte: Added accessibility rule
sveltejs / svelte ：添加了可访问性规则
sindresorhus/eslint-plugin-unicorn: Added lint rule
sindresorhus / eslint-plugin-unicorn ：添加了皮棉规则
microsoft/webtemplatestudio: Improved generated Angular and React code, fixed e2e tests
microsoft / webtemplatestudio ：改进了生成的Angular和React代码，修复了e2e测试
react-boilerplate/react-boilerplate: Dependency changes and upgrades
react-boilerplate / react-boilerplate ：依赖关系更改和升级
ethereum/ethereum-org-website: Fixed setTimeout leak, fixed accessibility issue
ethereum / ethereum-org-website ：修复了setTimeout泄漏，修复了可访问性问题
foundry376/mailspring: Added preferences options, allowed cancel upgrade prompt
Foundry376 / mailspring ：添加了首选项，允许取消升级提示

As you can see, my favorite areas in web development include working on code quality improvements, like linting and accessibility, as well as dependency upgrades.

如您所见，我在Web开发中最喜欢的领域包括致力于代码质量的改进，例如棉绒和可及性以及依赖项升级。

One of the great things about open source contributions is that you get to choose whichever issue you feel like working on right now!

开源贡献的伟大之处之一就是您可以选择自己喜欢的任何问题！

贡献流 (Contribution Flow)

Before starting to work on open source contributions, it is essential to know how the usual workflow looks.

在开始研究开源贡献之前，必须了解常规工作流程的外观。

Image for post — A high-level overview of the step by step flow that open source contributions follow (Image source: Author)

Although most pull requests can be created, reviewed, and merged within the same day, it is not uncommon for pull requests to take multiple months from start to finish. I have pull requests which are open for more than a year, and they are not merged yet because the project is maintained irregularly or project focus has moved away from that issue.

尽管大多数拉取请求都可以在同一天内创建，查看和合并，但拉取请求从头到尾要花费几个月的时间并不少见。我已经提出了超过一年的请求请求，但由于该项目的维护不定期或项目重点已从该问题转移到现在，所以它们尚未合并。

如何找到一个有助于项目 (How to Find a Project to Contribute To)

GitHub: There is an Explore page where GitHub recommends repositories based on your interests and previous contributions.
GitHub：有一个“ 浏览”页面，其中GitHub根据您的兴趣和以前的贡献推荐存储库。
Work: You are actively using a repository for a project at work. You want to fix a bug or add a feature that is necessary for your progress at work, or you simply want to contribute as a way of giving back to the project.
工作：您正在积极地使用项目的存储库。您想修复错误或添加工作进度所必需的功能，或者只是想回馈作为回馈项目的一种方式。
Contacts: You hear from coworkers or friends about cool repositories and want to be part of them, too.
联系人：您从同事或朋友那里听说了很酷的存储库，并且也希望成为其中的一员。
Stock Market: It’s not the most obvious way, but you could be invested in a company and want it to flourish.
股票市场：这不是最明显的方法，但是您可以投资于一家公司并希望它蓬勃发展。

Naturally, starting an open source project yourself if you have a great idea is an option as well.

当然，如果您有个好主意，也可以自己启动一个开源项目。

错误赏金计划 (Bug Bounty Programs)

Unfortunately, participation in most open source projects is voluntary and therefore unpaid, but there are websites where you can find issues with monetary rewards on them:

不幸的是，参与大多数开源项目是自愿的，因此是无偿的，但是在一些网站上，您可以找到涉及金钱奖励的问题：

Issuehunt: I collected various bounties of up to $100 for issues here, and the site gets updated regularly, so I highly recommend you check it out.
Issuehunt ：我在这里收集了高达100美元的各种奖励，问题站点会定期更新，因此，我强烈建议您检查一下。
Gitcoin: Most issues here are specific to blockchain development, and the payout is in cryptocurrency.
Gitcoin ：这里的大多数问题都是针对区块链开发的，而支出则是加密货币。
Bugcrowd
Bugcrowd
HackerOne
黑客一号
Bountysource
丰富资源

首先要做什么 (What to Do First)

Let’s assume that you found a project to your liking. Here are some ways that you can find out if it’s a smart idea to start working on that repository:

假设您找到了自己喜欢的项目。您可以通过以下几种方法来确定在该存储库上开始工作是否明智：

精通所使用的编程语言 (Be proficient with the programming language used)

No matter how great the project sounds, if you have no prior experience with the programming language or tech stack used, you will have a hard time fixing an issue.

无论项目听起来多么出色，如果您对使用的编程语言或技术堆栈没有任何经验，那么将很难解决问题。

检查项目的受欢迎程度 (Check the popularity of the project)

I recommend going for a project that is not too popular yet — all the good issues would be gone too quickly — but also not so small that the chance is high that the project might become unmaintained at some point. Aiming for a star count on GitHub between 1,000 and 50,000 is usually a good bet, but there are some exceptions.

我建议选择一个不太流行的项目-所有好的问题都将很快消失-但又不要太小，以至很有可能该项目在某个时候变得无法维护。通常，在GitHub上将星标定为1,000到50,000之间是一个不错的选择，但也有一些例外。

检查master分支中的最新提交 (Check the latest commit in the master branch)

Don’t contribute to a repository if you see that there was no commit added to master for more than a couple of months — that can be a sign of a deserted project. When having doubts about the ongoing development of the project, ask some contributors or open up a new issue.

如果您发现超过两个月没有向主数据库添加任何提交，则不要对存储库做出任何贡献-这可能是项目遗失的迹象。如果对项目的持续发展有疑问，请咨询一些贡献者或提出新的建议。

查看打开请求请求的数量 (Take a look at the number of open pull requests)

Are there a lot of open pull requests? If it is not a highly popular project, this can be a clear indicator that the repository cannot keep up and doesn’t have enough members for handling the reviews. Alternatively, it could also be that there are organizational issues that lead to slow decisions or that the direction of the project is lacking.

是否有很多开放请求请求？如果它不是一个非常受欢迎的项目，那么这可以清楚地表明存储库无法继续运行，并且没有足够的成员来处理评论。或者，也可能是由于组织问题导致决策缓慢，或者缺乏项目方向。

检查有待解决的有趣问题 (Check for interesting issues to work on)

Well-organized repositories usually have issue labels like “good first issue,” “help wanted,” or “documentation.” These can be an optimal start to get to know the repository. When you find a suitable issue, make sure it is not taken by someone else yet. If it’s an older issue, write a comment to find out if there is still a demand for a solution, to avoid working on an issue that’s not wanted anymore or superseded by other changes.

组织良好的存储库通常具有诸如“好第一期”，“需要帮助”或“文档”之类的标签。这些可能是了解存储库的最佳开始。当您找到合适的问题时，请确保尚未被其他人接受。如果是较旧的问题，请写评论以找出是否仍需要解决方案，以避免处理不再需要的问题或被其他更改所取代的问题。

查找项目的贡献准则 (Find contribution guidelines for the project)

While you can always find out how to get a project up and running locally yourself, a good project usually has information for contributors in the README.md file or more specifically in a dedicated CONTRIBUTING.md file.

尽管您总是可以找到如何在本地启动和运行项目的方法，但是一个好的项目通常在README.md文件中或更具体地在专用的CONTRIBUTING.md文件中具有供贡献者使用的信息。

在进行项目之前的准备工作 (Preparations Before Working on a Project)

By now, you have selected a project that fulfills all the criteria of being a good pick: It is continuously maintained, you found interesting open issues, and you feel skilled enough to start the work.

到目前为止，您已经选择了一个满足所有条件的项目，它是一个很好的选择：它得到了持续维护，发现了有趣的未解决问题，并且您足够熟练地可以开始工作。

(可选)确保将SSH密钥添加到您的GitHub帐户 ((Optional) Make sure to add an SSH key to your GitHub account)

With GitHub, you can clone a repository either with HTTPS or SSH. Various online discussions are going on about which way is better. I prefer and recommend SSH over HTTPS because you don’t have to re-enter your GitHub password every time you use operations like git push.

使用GitHub，您可以使用HTTPS或SSH克隆存储库。关于哪种方法更好的各种在线讨论正在进行中。我更喜欢并建议使用SSH而不是HTTPS，因为您不必每次使用git push类的操作时都重新输入GitHub密码。

If you are unsure about how to generate an SSH key and put it into your GitHub account, here is a good article: Connecting to GitHub with SSH.

如果您不确定如何生成SSH密钥并将其放入您的GitHub帐户，请阅读以下文章：使用SSH连接到GitHub 。

(可选)为已验证的提交添加GPG密钥 ((Optional) Add a GPG key for verified commits)

Although you can commit to a repository just fine without your commits being verified, I recommend setting up a GPG key for these three reasons:

尽管您可以在无需验证提交的情况下就可以提交到存储库，但是出于以下三个原因，我建议设置一个GPG密钥：

Your commit will receive a green Verified label which gives it improved authenticity.
您的提交将获得绿色的经过验证的标签，以提高其真实性。
You show other people involved in the project that the commit comes from a trusted source.
您向项目中涉及的其他人表明该提交来自受信任的来源。
Others can be sure that no one impersonated your account.
其他人可以确保没有人假冒您的帐户。

You can read more about generating a GPG key and verifying your commits here: Managing commit signature verification.

您可以在此处阅读有关生成GPG密钥和验证提交的更多信息：管理提交签名验证。

When you have your GPG key generated and set up in GitHub, it can be helpful to run these commands to tell git to auto-sign every commit:

在GitHub上生成并设置GPG密钥后，运行以下命令告诉git对每个提交进行自动签名会很有帮助：

git config --global user.signingkey <publickey> 
git config --global commit.gpgsign true

准备克隆 (Ready to clone)

Let’s say you want to contribute to React. The command for copying the project to your local disk would look like this:

假设您想为React做出贡献。用于将项目复制到本地磁盘的命令如下所示：

# ssh
git clone git@github.com:facebook/react.git# https
git clone https://github.com/facebook/react.git

After the project is successfully cloned to your local disk, you can find the repository available under the file path that you were located in when cloning it.

将项目成功克隆到本地磁盘后，可以在克隆项目所在的文件路径下找到可用的存储库。

查找用于开发的分支 (Find the branch used for development)

Before you start to work on the project and begin modifying files, it is a good idea to check the branches on the GitHub repo. Although most of the time you branch away from the master branch for your contributions, there are repositories that use a separate dev or development branch. These intermediate branches are used for pull requests and get merged back into master regularly when deciding on pushing out a new release.

在开始处理项目并开始修改文件之前，最好检查GitHub存储库上的分支。尽管大多数时候您会从master分支分支出来进行贡献，但是有些存储库使用单独的dev或development分支。这些中间分支用于请求请求，并在决定推出新版本时定期合并回master 。

熟悉项目 (Familiarize yourself with the project)

Depending on the size of the project, it can be quite the challenge to figure out which files require a change to provide a bug fix or feature. Try to scan the file structure once at least before using the search in your IDE for pinpointing the location for your code changes.

根据项目的大小，弄清楚哪些文件需要更改才能提供错误修复或功能可能是一个很大的挑战。尝试至少扫描一次文件结构，然后再在IDE中使用搜索来查明代码更改的位置。

不要气aged (Don’t get discouraged)

Starting with a large project can be overwhelming at first. I often wanted to give up on issues, only to find the ideal solution a moment later. It can pay off to be persevering.

首先，从大型项目开始可能会令人不知所措。我经常想放弃一些问题，只是在稍后找到理想的解决方案。坚持不懈可以得到回报。

Nevertheless, you will encounter projects — especially older ones — which can suffer from bad developer experience. When you realize that it will take you a lot of time to even get the project set up or the tests and linting to pass, focusing your work on another repository might be a better idea.

但是，您会遇到一些项目，尤其是较旧的项目，这些项目可能会遭受不良的开发人员经验的困扰。当您意识到建立项目或通过测试和评估将花费大量时间时，将工作重点放在另一个存储库上可能是一个更好的主意。

把事情做完 (Get Things Done)

At this point, you have familiarized yourself with the project, and you are sure that you can make some meaningful code changes.

至此，您已经熟悉了该项目，并且确定可以进行一些有意义的代码更改。

保留您选择的问题 (Reserve the issue of your choice)

You can signal to the contributors of the repository that you want to take an issue by simply writing “I want to work on this” as a comment. Ideally, you will get assigned to an issue and avoid having your issue taken by someone else.

您可以通过简单地写“我要处理此问题”作为注释来向存储库的参与者发出您要提出问题的信号。理想情况下，您将被分配给一个问题，并避免让别人来处理您的问题。

Be aware that you are expected to deliver a PR or a status update once you volunteer for an issue. Some contributors also might ask about the progress if it is a high-priority bug fix.

请注意，一旦您自愿解决某个问题，就有望提供PR或状态更新。一些贡献者还可能会询问进度，如果它是高优先级的错误修复程序。

将工作保存到分支 (Save work into a branch)

Since we are still in the default branch that we cloned the project from, it’s about time to check out into a separate branch to be able to commit.

由于我们仍在克隆项目的默认分支中，因此该是时候签入一个单独的分支以进行提交了。

I recommend naming a branch according to the <issue-number>-<issue-name> naming convention.

我建议根据<issue-number>-<issue-name>命名约定来命名分支。

An example of checking out into an issue-specific branch would look like this:

签入特定于问题的分支的示例如下所示：

git checkout -b 345-expose-options-for-gtag

If you want to read up more on the topic, there is plenty of information available about Git branch naming conventions.

如果您想阅读更多有关该主题的内容，则有很多有关Git分支命名约定的信息。

准备提交 (Ready to commit)

We already learned that there are naming conventions for creating branches in Git, so we also want to follow the best practices for the structure of a commit message. Conventional Commits is a good resource of “a specification for adding human and machine-readable meaning to commit messages.”

我们已经了解到在Git中创建分支的命名约定，因此我们也希望遵循最佳实践来落实提交消息。常规提交是“规范，以添加人和机器可读的含义来提交消息的规范”。

设置git commit默认消息 (Set up git commit default message)

As programmers, we prefer to avoid unnecessary work and stick to the DRY principle. That’s why I advise using a git commit default message. I have linked the template for you that I use myself. Whenever I start a commit message, I can check which type of change I’m working on and adapt the message and its body accordingly.

作为程序员，我们宁愿避免不必要的工作并坚持DRY原则。这就是为什么我建议使用git commit default message的原因。我已经链接了我自己使用的模板。每当我启动提交消息时，我都可以检查我正在处理的更改类型，并相应地调整消息及其主体。

A useful hint: Whenever you put the issue number into your commit message like (#<issue-number>), the respective issue on the remote repository will receive a timeline notification that looks like this:

一个有用的提示：每当将问题编号放入(#<issue-number>)类的提交消息中时，远程存储库上的相应问题将收到如下所示的时间轴通知：

This can be helpful, especially for pull requests that span a longer time frame to further signal to other subscribers of an issue that you are indeed working on it right now and that the pull request is not abandoned.

这可能会有所帮助，特别是对于跨越较长时间范围的拉取请求，以进一步向其他订阅者发出信号，告知您您确实正在处理该问题，并且未放弃拉取请求。

检查如何在您选择的存储库中完成提交 (Check how commits are done in the repository of your choice)

Although you are good to go most of the time with sticking to the conventional commit structure for commits, I advise running git log in a project where you contribute for the first time, to see how strict commit messages are handled.

尽管您大多数时候都愿意坚持使用常规的提交结构来提交，但是我建议您在您第一次参与的项目中运行git log ，以了解如何处理严格的提交消息。

确保您遵守概述的缴费准则 (Make sure you comply with the outlined contribution guidelines)

Before committing, double-check that you fulfill all the requirements of a potential CONTRIBUTING.md file. Whenever you add a new feature, it can be a requirement to add a corresponding unit test to the project to verify that your changes are reliably working or that you updated the documentation to explain the feature.

提交之前，请仔细检查您是否满足潜在CONTRIBUTING.md文件的所有要求。每当您添加新功能时，都可能需要向项目中添加相应的单元测试，以确认所做的更改能够可靠地工作，或者您更新了文档以解释该功能。

专注于手头的问题 (Focus on the issue at hand exclusively)

Don’t touch any code not related to the bug you are fixing or the feature you are implementing, and stick to the code style of the project.

请勿触摸与正在修复的错误或正在实现的功能无关的任何代码，并坚持使用项目的代码风格。

Sometimes, the pull request reviewers will also explicitly tell you to revert formatting or refactoring changes that you did out of goodwill. The main reason is to keep the pull request easy to read and review and to avoid time-consuming discussions about irrelevant changes in the code diff.

有时，拉取请求审阅者还会明确告诉您还原出于商誉而进行的格式化或重构更改。主要原因是使pull请求易于阅读和查看，并避免了有关代码差异无关更改的耗时讨论。

壁球提交 (Squash commits)

Do as many commits as you need while the pull request is in a work-in-progress state, but rewrite and squash your commits to result in one nice and clean commit in the end. This way you avoid polluting the master branch with excess information in git log.

在pull请求处于进行中状态时，您可以根据需要执行任意数量的提交，但是重写并压缩您的提交，最终得到一个很好的干净提交。这样，您可以避免git log过多的信息污染master分支。

In case you are unfamiliar with squashing commits, this beginner’s guide to squashing commits with git rebase can help you out.

如果您不熟悉压缩提交，那么本本使用git rebase压缩提交的初学者指南可以为您提供帮助。

准备推送 (Ready to push)

If you’ve gotten this far, great! You’re almost ready to open your first PR. There are only a few steps left.

如果您已经走了那么远，那就太好了！您几乎准备打开您的第一个PR。只剩下几步了。

货叉库 (Fork repository)

Forking is just a fancy word for taking a repository on GitHub and copying it under your own GitHub username. It can be done by clicking the Fork button on the right upper corner on any repository as can be seen here:

对于在GitHub上建立存储库并将其复制到您自己的GitHub用户名下，Forking只是个花哨的词。可以通过单击任何存储库右上角的Fork按钮来完成，如下所示：

The reason why we need to fork a repository is to be able to submit a pull request against it. By default, you don’t have push permissions to a repository that doesn’t belong to you. Therefore, we fork a repository under our username where we are allowed to push to, and then we can submit a PR against the original GitHub repository.

我们之所以需要派生存储库，是为了能够对它提交拉取请求。默认情况下，您没有对不属于您的存储库的推送权限。因此，我们在允许推送到的用户名下分叉一个存储库，然后我们可以针对原始GitHub存储库提交PR。

So if you decide to fork React, it will take a few seconds, and then you will have an exact copy of the repository available under https://github.com/<username>/react.

因此，如果您决定分叉React ，这将花费几秒钟，然后您将在https://github.com/<username>/react下获得可用的存储库副本。

Although the step of forking can be done earlier in the workflow, at this point we already made a git commit previously, so we know for sure that we have a meaningful contribution to push. If you fork a repository before checking out the project locally and finding out if you can do valuable changes, it can be that you decide against working on it, and then you forked it in vain.

尽管分叉的步骤可以在工作流中更早地完成，但在这一点上，我们之前已经进行了git commit ，因此我们可以肯定地知道了我们对推送的贡献。如果您在本地检出项目并确定是否可以进行有价值的更改之前派生一个存储库，则可能是您决定不对其进行处理，然后徒劳地将其分叉。

设置一个git遥控器 (Set up a git remote)

When you clone a repository from GitHub to your local disk, it has the origin set up for you.

当您将存储库从GitHub复制到本地磁盘时，它具有为您设置的origin 。

If you run git remote -v inside the location where you cloned the repository to, it should look similar to this: origin git@github.com:facebook/react.git.

如果您在将存储origin git@github.com:facebook/react.git到的位置内运行git remote -v ，则它应类似于以下内容： origin git@github.com:facebook/react.git 。

When you run git push, it will try to push against origin, which would not work in this case since we are not a member of the Facebook group.

当您运行git push ，它将尝试对origin进行推送，因为我们不是Facebook组的成员，因此在这种情况下将不起作用。

We need to change the origin to be our fork and the upstream repository to be facebook/react.

我们需要改变的origin是我们的叉子和upstream资源库是Facebook的/React 。

To do that, we can run:

为此，我们可以运行：

# add facebook/react as upstream
git remote add upstream git@github.com:facebook/react.git # change origin url to be <username>/react
git remote set-url origin git@github.com:<username>/react.git

If you did everything correctly, the output of git remote -v should display that origin and upstream are set up:

如果您正确执行了所有操作，则git remote -v的输出应显示已设置origin和upstream ：

Does it look similar to the screenshot above? Good job!

它看起来与上面的屏幕截图相似吗？做得好！

推到原点 (Push to origin)

The remaining steps should be fairly easy. We push our branch with the squashed commits that we made to the origin, which is our fork.

其余步骤应该相当简单。我们使用对origin (即分叉)所做的压缩提交来推动分支。

The command to do that is:

执行此操作的命令是：

git push origin <branch-name>

Super, we are almost through.

超级好，我们快完成了。

准备打开公关 (Ready to open a PR)

If you did everything correctly, you will be presented with an alert box at the location of your forked repository notifying you of your recent push.

如果您正确执行了所有操作，则会在分叉存储库的位置向您显示一个警报框，通知您最近的推送。

After you are 100% done with your work, click the “Compare & pull request” button.

工作完成100％后，请单击“比较并提取请求”按钮。

编写有用的请求请求描述 (Write a useful pull request description)

To make the review for the maintainers of the repository as easy as possible, we should follow the best practices for a good pull request description.

为了使对存储库维护者的审查尽可能容易，我们应遵循最佳实践，以获取良好的请求请求描述。

This is the minimum that I would put there:

这是我要输入的最小值：

Closes #<issue-number>.  <explanation>

GitHub will parse the “Closes” keyword and automatically close the issue when the PR gets merged.

GitHub将解析“ Closes”关键字，并在PR合并后自动关闭该问题。

The <explanation> part can be very different depending on your contribution. It might be that you want to explain the bug that you fixed, notify about potential problems that could show up in the future, or discuss breaking changes that your PR might lead to.

<explanation>部分可能会有所不同，具体取决于您的贡献。可能是您想解释所修复的错误，通知将来可能出现的潜在问题，或者讨论PR可能导致的重大更改。

Additionally, some repositories might have dedicated pull request templates set up. Then you would need to check checkboxes making sure that, e.g., linting goes through without errors, you added unit test cases for your new feature, or no formatting changes were committed, depending on the repository.

此外，某些存储库可能设置了专用的拉取请求模板。然后，您将需要选中复选框，以确保(例如)无棉绒检查顺利进行，是否为新功能添加了单元测试用例，或者没有提交格式更改，具体取决于存储库。

When you are content with your pull request description, the only thing left to do is to click that rewarding, green “Create pull request” button, and voilà!

当您对请求请求的描述感到满意时，剩下要做的就是单击绿色的“创建请求请求”按钮，然后点赞！

等待批准 (Wait for approval)

Depending on the project, this can happen quickly or take a while. Sometimes you will have to do multiple iterations of improvements for a pull request; other times, your work will be merged right away.

根据项目的不同，这可能会很快发生，也可能需要一段时间。有时，您必须为请求请求进行多次迭代的改进；其他时间，您的工作将立即合并。