Shulou(Shulou.com)06/02 Report--

This article mainly explains "how to make a perfect Pull Request". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to make a perfect Pull Request".

1. Add code comments about "why"

When writing a new feature, there will be a lot of information about it. Code should be written with full consideration of requirements, limitations of third-party systems, and interaction with legacy code bases. But others don't know the source of the context, so when they see this code, they ask, "Why is it here?" Or "Why did you choose this method?" So let the reader of the code know "why" in advance by adding explanatory comments. The author does not agree with the view advocated by some people that notes are harmful and should be ignored.

There are many kinds of comments. Those who describe the purpose of the code are really cumbersome. This hassle can be eliminated by extracting a method and using a carefully selected name. On the other hand, explaining why the code is written in this way also increases the amount of information for the code reader. These comments ideally raise the reader's cognitive level to the same level as the coders, which helps to improve the understanding of the code.

The author's comments usually give the reasons for the existence of the class, links to related resources, and the causes and consequences of the code:

# First Crew Dragon launch was postponeddue to bad weather, # and now we needan event for the "second" first launch. # Hence the stupidname. ClassSecondFirstCrewDragonLaunch... End

two。 A clear description

The description of pull request provides the reviewer with the initial context of the task, including:

A link to the label.

A summary of completed events (if you can't see it in the title of pullrequest).

Links to related pull request (for example, related changes in another service).

Instead of including the information you think you need to understand the code in the description of pullrequest, you should comment on the code: they are more effective and helpful to future code readers.

3. Streamlined pull request

This is such a powerful technology that Google even wrote a separate article on the benefits of a small pullrequest (https://google.github.io/eng-practices/review/developer/small-cls.html). Here are my favorite features of a mini pull request:

More thorough censorship

Review is faster

Easier to merge (frequent mergers can reduce conflicts)

If rejected, less energy is wasted.

The following methods can make it easier to write a small pull request:

Extract the refactoring into a separate pull request

Break down large functions (even if they are not user-oriented)

It's helpful to learn some git tips. Think of git add-patch and git rebase-interactive as friends.

Set the long-running functional branch as the goal of pull request, not the goal of master:

4. Quick response to review

Processing review comments is usually time-consuming, requiring fixing typos, adding missing test cases, renaming methods, and so on. If you can finish it quickly, your partner can spend less time memorizing information related to pull request.

But the disadvantage of this approach is that it increases the workload of context switching. The alternative is to use the Tomato work method (Pomodoro technique): interspersed with a short break every 25 minutes. It can make people more focused, more productive, healthier, and reduce fatigue, and context switching after a break will be more natural. The negative destructive effects will not disappear, but they will be greatly reduced.

5. Comment on your own pull request

It doesn't make sense to add explanatory code comments to some changes, such as deletions and refactorings, and you should consider giving your own pull request comments more context to the reviewer.

6. Rebasing the new pull request before creating the master

This has many benefits:

The test may pass in the local branch, but fail when the most recent update is applied.

You can use newly added features (such as new tool classes).

Censors will be confused if they fail to find recent changes.

The author prefers rebasing to merging, because rebasing causes branches to contain only related commits.

7. Do not modify reviewed submissions-send new ones

Review comments are processed in a separate submission, rather than modifying or removing changes. This makes it easier for reviewers to check changes that have occurred since the last review:

8. Discuss the overall approach before implementing the function

This can save a lot of time. Before you deal with more complex refactoring and functionality, discuss the approach with your colleagues. Discuss with other developers to explain the task and your ideas, and they may agree or come up with a better way.

Most of the time, the author is faced with the lack of preliminary coordination, and the results of several days of work are wasted. Imagine you do something for five days in a row, only to hear, "Sorry, we don't need it." To save yourself from disappointment, you need to get feedback as soon as possible.

Thank you for your reading, the above is the content of "how to make a perfect Pull Request". After the study of this article, I believe you have a deeper understanding of how to do a perfect Pull Request, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.