git拉取请求_创建有效拉取请求的技巧

Pull Requests (PR) are crucial to almost all software development these days. They have became a lot more accessible and easier to perform thanks to all the various features from different source control platforms such as GitHub and Bitbucket.

拉取请求(PR)对当今几乎所有软件开发都至关重要。 由于来自不同源代码控制平台(例如GitHub和Bitbucket)的所有功能，它们变得更加易于访问和易于执行。

However, PRs are still considered by a lot of the developers mostly as something that need to get approved in order to get their code merged. They often treat it as a hide and seek game and try to hide things from reviewers.

但是，PR仍然被许多开发人员认为大部分都是需要批准才能合并其代码的东西。 他们通常将其视为“捉迷藏”游戏，并试图将内容隐藏在审稿人面前。

Why do we send Pull Requests? Let’s take a step back and reconsider the main purpose of sending a Pull Request.

为什么我们发送拉取请求？ 让我们退后一步，重新考虑发送请求请求的主要目的。

Pull Request is to ask others to help you have a look at your codes and give you feedback. It is a mechanism to learn from others.

拉取请求是要求其他人帮助您查看代码并提供反馈。 这是一种向他人学习的机制。

Helping you have a look at your codes is the key takeaway here.

帮助您查看代码是这里的重点。

Whoever reviewing your PR is doing you a favor. They are spending a lot of their time trying to help you catch potential issues before they show up as bugs in production. In order to do so, they have to spend a significant amount of their time to try and understand what you are trying to achieve on top of their busy schedule and workload.

谁审查您的公关正在帮您一个忙。 他们花费大量时间试图帮助您发现潜在的问题，然后将它们显示为生产中的错误。 为了做到这一点，他们必须花费大量的时间来尝试并了解他们在繁忙的日程安排和工作量之外要达到的目标。

不良的公关看起来像什么 (What Does a Bad PR Looks Like)

This is a very good example of what not to do when sending a PR.

这是发送PR时什么不能做一个很好的例子。

How many bad things did you notice from the above PR? Imagine someone from your team send it to you and ask you to review the PR.

您从上述PR中注意到了多少坏事？ 想象一下，您团队中的某人将其发送给您，并要求您检查PR。

An abstract title, only the auto generated list of commits messages in the description section, 100+ files being updated with just 6 commits.

一个抽象标题，仅描述部分中的自动生成的提交消息列表，仅用6次提交即可更新100多个文件。

How long will it take for you to properly review this PR assuming you are not familiar with what they are trying to achieve or the details of the task they are working on? Will you still try to give a good code review or like most of us, will you simply click “approve” after a brief scroll through the code?

假设您不熟悉他们要实现的目标或他们正在执行的任务的详细信息，您需要多长时间才能正确查看此PR？ 您仍然会尝试对代码进行良好的审查吗？还是像我们大多数人一样，在简短滚动代码后是否只需单击“批准”？

Remember, why should the code reviewers care if the one requesting code review doesn’t?

记住，为什么代码审阅者不关心请求代码审阅的人呢？

改善提货要求的3种方法 (3 Ways To Improve Your Pull Requests)

Now that we know what we shouldn’t do, let’s have a look at what we should be doing.

现在我们知道了不应该做的事情，让我们看一下我们应该做的事情。

Here are 3 simple points to make it easier for your code reviewers to review your code quickly and efficiently. Not only your codes will get reviewed faster, it will get reviewed more thoroughly.

这里有3个简单的要点，可以使您的代码审阅者更快速，更有效地审阅您的代码。 不仅您的代码将得到更快的审查，而且将得到更彻底的审查。

1.保持小巧并保持清洁 (1. Keep It Small & Keep It Clean)

Don’t do one big commit with all of the different changes— indentation fixes, refactoring, and then the actual important changes.

不要对所有不同的更改进行一次大的提交-缩进修复，重构，然后进行实际的重要更改。

Organize your individual commits and keep them clean. Put all the code clean up — indentation fixes, simple refactoring — in a separate commit and mention it in the code review description. That will allow your code reviewer to be able to review the PR commit by commit. They can go quickly over the cleanup commit and spend more time on commits which include the actual important changes.

组织您的个人承诺并保持其清洁。 将所有清理的代码(缩进修复，简单的重构)放在单独的提交中，并在代码查看描述中提及。 这将使您的代码审阅者能够按提交审阅PR提交。 他们可以快速完成清理提交，并花更多的时间进行提交，包括实际的重要更改。

In order for this to work, the commit message should be descriptive enough so that the reviewers will know which one they can skim through and which one they should pay attention to. And make sure each commit is grouped by feature or function. If not, the code would not make sense to the reviewers when they review commit by commit.

为了使此功能有效，提交消息应具有足够的描述性，以便审阅者知道可以略过哪些内容以及应该注意哪些内容。 并确保每个提交都按功能或特性分组。 如果不是这样，那么当审阅者逐个提交地审阅代码时，该代码对审阅者就没有意义。

Using git rebase and selective commit make it easier to keep your commits small and clean.

使用git rebase和有选择的提交可以使保持较小和干净的提交更加容易。

2.提供您要做什么的概述和背景 (2. Provide Overview & Background Of What You Are Trying To Do)

Description should contain the overview of the feature or the background about the changes. Your reviewers are busy and occupied with their own tasks. Don’t expect them to know what you are working on. Provide screenshot if it helps make it easier for the reviewers — especially for UI changes.

描述应包含功能的概述或有关更改的背景。 您的审阅者很忙，忙于自己的任务。 不要指望他们知道您在做什么。 提供屏幕截图(如果它有助于使审阅者更轻松，尤其是UI更改)。

• It should not be just repeating the relevant comments that have already been put in the code or the commit messages. Instead, cover why the changes are made or the overall feature that is implemented by the PR.
  它不应该只是重复在代码或提交消息中已经添加的相关注释。 相反，请说明进行更改的原因或PR实施的总体功能。
• If the PR is for a new feature, then indicate the unusual cases which have been considered in the description — if nothing is specified, then it will be assumed that corner cases are not yet considered and the reviewer can put some focus on those cases while doing the review. This will help reduce the number of bugs found by QA or worse, bugs in production.
  如果PR是针对新功能的，则请指出描述中已考虑的异常情况-如果未指定任何内容，则将假定尚未考虑过极端情况，并且审阅者可以将重点放在这些情况下，做审查。 这将有助于减少质量检查发现的错误的数量，或者减少生产中的错误的数量。

3.提及的关注领域或您要审查的领域 (3. Mention Areas of Concern Or Area You Want To Get Reviewed)

If there is any particular area you would like to get reviewed, then mention them in the PR. It allows the reviewer to pay more attention to those areas - things concerning performance, use cases, architecture, design etc.

如果您要审核任何特定领域，请在PR中提及。 它使审阅者可以更加关注这些领域-有关性能，用例，体系结构，设计等方面的信息。

For PR with complex changes, try to annotate code before the code reviewer starts reviewing. Annotations will help guide the reviewer through the changes, showing which files to look at first and you can also explain the the reason behind each code modification. It helps ease the reviewing and also provides more context to the reviewers.

对于具有复杂更改的PR，请在代码审阅者开始审阅之前尝试对代码进行注释。 注释将帮助指导审阅者进行更改，显示首先查看哪些文件，还可以解释每次代码修改背后的原因。 它有助于简化审阅过程，并为审阅者提供更多上下文。

结语 (Wrapping Up)

There is no definitive right or wrong way when it comes to pull requests. Each teams has their respective definitions of optimal pull request size and format. And there will always be situations where a small PR might not be possible.

拉取请求没有确定的正确或错误方法。 每个团队都有各自的最佳拉取请求大小和格式的定义。 在某些情况下，可能无法实现小的PR。

Communicate with your reviewers and try out different ways to improve the code review process of the team. The small time that was spent on improving the code review process will save the team hours of debugging and releasing patches later down the line.

与您的审阅者进行交流，并尝试不同的方法来改善团队的代码审阅过程。 花在改进代码审查过程上的少量时间将节省团队调试和稍后发布补丁程序的时间。