拉力采集_拉力点到底是什么要求

拉力采集

If you are a beginner in the world of Git and hosted Git platforms (such as GitHub or GitLab), then you’ve probably never heard the term “pull request” or “merge request” before. You also might not understand what they are or the value they bring to your team.

如果您是Git领域的初学者并托管Git平台(例如GitHub或GitLab)，那么您以前可能从未听说过“拉动请求”或“合并请求”一词。 您也可能不了解它们是什么或它们给团队带来的价值。

Sidenote: I’ll be using the term “pull request in this article, but it’s effectively the same as a “merge request” in GitLab.

旁注：我将在本文中使用术语“拉取请求”，但实际上与GitLab中的“合并请求”相同。

Pull requests help teams build and share software. They do have a bit of a learning curve though, but I believe its worth it. My goal in this article is to help you get familiar with pull requests and how they fit into the flow of building software.

拉取请求帮助团队构建和共享软件。 他们确实有一些学习曲线，但是我认为这是值得的。 我在本文中的目标是帮助您熟悉拉取请求以及它们如何适应构建软件的流程。

什么是拉取请求？ (What is a Pull Request?)

A pull request is really just a request to pull/integrate changes from one branch to another. This might be from a branch with a single commit from one developer, or a branch with multiple commits and authors. In most cases, a pull request is used to integrate a new feature or bug fix into the project’s main branch.

拉取请求实际上只是将请求从一个分支拉取/集成到另一个分支的请求。 这可能来自具有一个开发人员一次提交的分支，也可能来自具有多个提交和作者的分支。 在大多数情况下，拉取请求用于将新功能或错误修复集成到项目的主分支中。

A pull request also includes a short description of the changes and why they are being made. There is usually a discussion amongst the author of the pull request and a set of reviewers. Reviewers are just other developers that have worked on the project and can provide feedback on the changes. In open-source projects, these reviewers will typically be core contributors or maintainers. In other cases — like with your team at work — the reviewers will typically be senior engineers or teammates.

提取请求还包括对更改及其进行原因的简短描述。 拉取请求的作者和一组审阅者之间通常会进行讨论。 审阅者只是从事该项目并可以提供有关更改反馈的其他开发人员。 在开源项目中，这些审阅者通常将是核心撰稿人或维护者。 在其他情况下(例如与您的团队一起工作)，审阅者通常是高级工程师或队友。

Here is an image of a pull request in GitHub with a simple description referencing an issue:

这是GitHub中的pull请求的图像，其中包含引用问题的简单描述：

Now that we have defined a pull request, let’s look at why they are so popular and helpful.

既然我们已经定义了请求请求，让我们看看为什么它们如此受欢迎和有用。

通讯 (Communication)

At their root, pull requests help by making it easy to collaborate with others. They allow for transparent communication between authors and reviewers by showing diffs, commits, and facilitating comments about the changes.

从根本上讲，拉取请求通过使其易于与他人协作而有所帮助。 通过显示差异，提交并促进对更改的评论，它们允许作者和审阅者之间进行透明的沟通。

Before pull requests, changes were submitted via email or IRC channels with the branch name or a set of commits. For changes to be merged, a maintainer or release engineer would be responsible for comparing the changes on their local computer, offering feedback, and waiting for a response with additional changes. They would then have to merge the changes on their local machine and push them to the origin. Pull requests make this much simpler.

在请求请求之前，通过电子邮件或IRC通道使用分支名称或一组提交提交更改。 对于要合并的更改，维护人员或发布工程师将负责比较其本地计算机上的更改，提供反馈并等待其他更改的响应。 然后，他们将不得不在本地计算机上合并更改并将其推送到源。 拉取请求使这一过程变得更加简单。

This is especially true for large projects with tons of contributors. Many open-source projects follow this pattern for that reason. Often, these projects follow a workflow called “GitHub flow.” GitHub flow focuses on forking whole projects and creating pull requests across those forks.

对于有大量贡献者的大型项目尤其如此。 因此，许多开源项目都遵循这种模式。 通常，这些项目遵循称为“ GitHub流”的工作流。 GitHub流专注于分叉整个项目并在这些分支之间创建拉取请求。

If that sounds intimidating at first, don’t worry! Just remember that the core idea is the same; requesting changes from one branch to be incorporated into another. You can read more about forks and the GitHub Flow on the official git-scm site.

如果一开始听起来很吓人，请放心！ 请记住，核心思想是相同的。 要求将一个分支的更改合并到另一个分支。 您可以在git-scm官方网站上阅读有关fork和GitHub Flow的更多信息。

Another benefit of the pull request flow is that all communication about a set of changes is now open for all to see. They are searchable, taggable, and relatively easy to keep track of. This means context and previous decisions aren’t buried in email threads or chat windows. Instead, they are easily searchable, taggable, and viewable to everyone.

拉取请求流的另一个好处是，现在可以打开所有有关一组更改的通信，以供所有人查看。 它们是可搜索的，可标记的，并且相对易于跟踪。 这意味着上下文和先前的决定不会被埋在电子邮件线程或聊天窗口中。 取而代之的是，每个人都可以轻松地搜索，标记和查看它们。

自动化 (Automation)

As pull requests became popular amongst the development community, GitHub and other Git-hosting platforms created a rich set of webhooks designed around the GitHub flow to enable automation. It is common these days for continuous integration tasks to take place on every commit that is part of a pull request for this reason. In my experience, this is one of the most leveraged places for automation. And not just running automated tests.; you can deploy entire environments from the changes in the pull request and see if the deploy was successful.

随着拉动请求在开发社区中变得越来越流行，GitHub和其他Git托管平台创建了一系列围绕GitHub流设计的丰富Webhooks ，以实现自动化。 出于这种原因，如今在连续的整合请求中，通常对属于拉取请求的每个提交都执行连续集成任务。 以我的经验，这是自动化最充分利用的地方之一。 而不仅仅是运行自动化测试。 您可以根据拉取请求中的更改部署整个环境，并查看部署是否成功。

It used to be that such tools or integrations were expensive. Either a team had to maintain infrastructure for their automation tasks, or they had to pay for hosted services. Recently, many more tools have become available to make it even easier to set up such tasks. Companies like Netlify and Travis have free offerings for many projects that you can take advantage of.

过去，此类工具或集成非常昂贵。 团队要么必须维护其自动化任务的基础架构，要么必须为托管服务付费。 最近，有更多工具可供使用，以使设置此类任务更加容易。 像Netlify和Travis这样的公司都为您可以利用的许多项目提供免费产品。

GitHub took this even further with the advent of GitHub Actions. Actions allow you to build your automation workflows from a marketplace of small, discrete, and composable tasks. You should really check them out!

GitHub随着GitHub Actions的出现而进一步发展。 通过操作，您可以从小型，离散和可组合任务的市场构建自动化工作流。 您应该真正检查一下它们！

状态检查 (Status Checks)

The last big benefit of pull requests is the concept of status checks. Status checks are just a set of tasks that are executed for every commit in the pull request and a “success” or “failure.” In a very real sense, status checks have become a checklist that the changes are good to go.

拉取请求的最后一个大好处是状态检查的概念。 状态检查只是针对拉取请求中的每个提交以及“成功”或“失败”执行的一组任务。 实际上，状态检查已经成为变更的检查清单。

Status checks can be used for whatever you want them to be. Most teams will have automated tests as one, style checkers as another, and then a requirement for one or two code review approvals. The changes can’t be merged unless all these checks have been met.

状态检查可用于任何您想要的状态。 大多数团队将自动测试作为一种，将样式检查器作为另一种，然后要求获得一两个代码审查批准。 除非已满足所有这些检查，否则无法合并更改。

The topic of code reviews is something worth mentioning in a little more detail as well. Because the ability to communicate and collaborate is so effective on a pull request, many teams use this as a natural place to review code. Pull requests can even manage reviewers, their reviews, and approval status right from the pull request page. Many large projects even have automation to add specific users or groups to a pull request based on the files that have changed. For example, take a look at the CODEOWNERS documentation.

代码审查的主题也值得一提。 由于交流和协作的能力对请求请求非常有效，因此许多团队将其用作查看代码的自然场所。 拉取请求甚至可以直接从拉取请求页面管理审阅者，其审阅和批准状态。 许多大型项目甚至可以根据更改的文件自动将特定的用户或组添加到拉取请求中。 例如，看一下CODEOWNERS文档。

To summarize, a pull request is just a request to integrate changes from one branch to another. While so simple, pull requests are powerful which is why they have become the epicenter of modern development. Pull requests facilitate continuous integration tasks, code reviews, and checklists to keep quality high. They have transformed a repository from being something that stores only source code to something that stores knowledge about that source.

总而言之，拉取请求仅是将更改从一个分支集成到另一个分支的请求。 尽管如此简单，但请求请求却很强大，这就是为什么它们已成为现代发展的中心。 拉取请求有助于进行持续的集成任务，代码审查和清单，以保持较高的质量。 他们已经将存储库从仅存储源代码的存储库转变为存储有关源代码的知识的存储库。

This is also where most learning happens! Some of the most important lessons I’ve learned about software development have come from feedback from patient individuals on pull requests-lessons on coding, Git, project management, and career growth too.

这也是大多数学习的地方！ 我所学到的有关软件开发的一些最重要的经验教训，来自患者个人在请求请求方面的反馈，包括关于编码，Git，项目管理和职业发展的经验教训。

Happy coding!

编码愉快！

Originally published at https://dangoslen.me.

最初发布在https://dangoslen.me 。

翻译自: https://codeburst.io/whats-the-point-of-pull-requests-anyway-f6824890c6e9

拉力采集