java代码发送请求并传参_如何优化您的请求请求并使代码审核人员满意

java代码发送请求并传参

Imagine reading a novel, but having the chapters sliced up and reordered alphabetically by title. Or what if you were watching a movie, but the scenes were reordered alphabetically by their first words of spoken dialog?

想象一下读一本小说，但是将各个章节切开，然后按标题的字母顺序重新排列。或者，如果您正在看电影，但是场景的语音对话的第一个单词按字母顺序重新排序，该怎么办？

Puzzling a narrative back together from these shuffled pieces might sound fun, but the novelty would wear off quickly if reviewing and understanding these stories were part of your day-to-day responsibilities.

将这些杂乱无章的片段重新组合在一起听起来听起来很有趣，但是如果您回顾并理解这些故事是您日常职责的一部分，那么新颖性就会很快消失。

代码中的混搭叙述 (Shuffled narratives in code)

The "Files changed" view for pull requests on Github lists changes alphabetically by file path. That's fine for the small feature branches that we strive for, but there are often complex changes with interdependent pieces that unavoidably result in large diffs across multiple files. Those changes can be overwhelming for reviewers to look at using the alphabetically-sorted files view.

Github上的拉取请求的“文件已更改”视图按文件路径的字母顺序进行更改。对于我们努力争取的小型功能分支来说，这很好，但是经常会发生相互依赖的部分的复杂更改，这些更改不可避免地会导致多个文件之间出现较大差异。对于审阅者而言，使用按字母顺序排序的文件视图来查看这些更改可能会令人不知所措。

Instead, reviewers can view these changes in smaller more isolated chunks (i.e. commit-by-commit). Each commit's message can convey what the change is meant to achieve. And commits in sequence convey a sensible narrative for why these changes were necessary for this feature branch. All of this makes the reviewer's job much easier and more pleasant.

相反，审阅者可以在更小，更孤立的块中查看这些更改(即逐个提交)。每个提交的消息都可以传达更改的意图。并且顺序提交传达了一个明智的叙述，说明为什么这些更改对于此功能分支是必需的。所有这些使审阅者的工作更加轻松和愉快。

准备清晰的提交历史 (Prepare a clear commit history)

Thorough use of partial-staging, amending, and rebasing are all tools that will help achieve a clean commit history that your reviewers will appreciate.

充分使用部分登台，修改和重新定基都是所有工具，这些工具将有助于实现清晰的提交历史记录，您的审阅者会很欣赏。

Avoid creating loosely focused commits. You might have forgotten to commit changes that made sense to be logically grouped together and continued on with editing the file. That's okay, happens all the time. Just because a file contains changes doesn't mean all those changes need to be committed.

避免创建过于集中的提交。您可能已经忘记提交有意义的更改，这些更改在逻辑上被分组在一起，并继续编辑文件。没关系，一直在发生。仅仅因为文件包含更改并不意味着所有这些更改都需要提交。

You also don't have to undo the changes that aren't related. You can use interactive staging to pick which chunks of a file should be staged for commit and which should be left for a future commit.

您也不必撤消不相关的更改。您可以使用交互式暂存来选择应暂存文件的哪些块以进行提交，以及将哪些留给以后的提交。

Aggressively rebase to avoid creating commits whose changes are later significantly modified or even deleted.

积极地进行基础调整，以避免创建其更改后来被重大修改甚至删除的提交。

It can be frustrating for a reviewer to spend time understanding what changed in one commit, then find that they'd essentially wasted their time on dead code a few commits later. Amend/fixup/squash those changes before you ask for a review!

审阅者花时间了解一次提交中的更改，然后发现他们本质上在稍后的几次提交中浪费时间在无效代码上可能会令人沮丧。在您要求审查之前，修改/修正/压缩这些更改！

If that sounds like a hassle, which is a reasonable reaction since git is hardly known for its UX, I highly recommend considering a Git GUI that can make much of that painless.

如果象是一种狡辩，这是一个合理的React，因为Git是很难以其UX那个声音，我强烈建议考虑一个Git GUI，可以使多，的无痛。

要求审查 (Request a review)

After you have requested colleagues to review the pull request, stop rebasing your commits! Push changes requested by reviewers into new commits instead.

在您要求同事审查请求请求之后，请停止对提交进行重新评估！将审阅者请求的更改推送到新提交中。

"But doesn't this go against the goal of keeping a clean commit history?"

“但这不违背保持干净提交历史的目标吗？”

Keeping a clean commit history was not the end goal, but rather a means towards making your changes easier for others to understand and review. Once a review has begun, modifying your commits actually makes your new changes harder to review.

保持干净的提交历史记录不是最终目标，而是使您的更改更易于他人理解和审查的一种手段。一旦审查开始，修改提交实际上会使您的新变更难以审查。

Say you opened a pull request with these commits

假设您使用这些提交打开了请求请求

java代码发送请求并传参_如何优化您的请求请求并使代码审核人员满意 — (pseudo commits for demo purposes (ease-of-reference); don't actually number your commit messages)

A reviewer then leaves a comment on something that was related to changes made in the first commit. If you modify that commit and force push, your old commits disappear from the pull request, and all commits since the ones that were rebased will appear as new commits following that review

然后，审阅者会对与第一次提交中所做的更改相关的内容发表评论。如果您修改该提交并强制执行推送，则旧的提交将从拉取请求中消失，并且自从经过重新定位的提交以来，所有提交都将在审阅后显示为新提交。

What's changed since the last time a reviewer looked at the pull request?Which commits have been modified and thus require attention, which haven't and can be skipped?

自从上次审阅审稿人请求以来，发生了什么变化？哪些提交已被修改，因此需要引起注意，哪些尚未且可以跳过？

The only way to tell is to look at all the commits that were force pushed, and try to recall whether what you see now is different from what was there before.

唯一的告诉方法是查看所有被强制执行的提交，并尝试回想一下您现在看到的内容是否与以前有所不同。

If you try to click on the file that was commented on to see if the comment had been addressed, or to get more context for code around the area of where the comment was made you'll be greeted with this charming telescope

如果您尝试单击带有注释的文件，以查看注释是否已解决，或者在注释所在区域获得更多代码上下文，您将受到这款迷人的望远镜的欢迎

Going back to the analogy of reading a novel – imagine making it halfway through, leave it alone for a day or two, and when you pick it back up you're told that important pieces in the parts you've read have changed, and the only way to know exactly what's changed is to read it all over again. Not fun.

回到类似于读小说的类比–想象半途而废，让它呆一两天，当你拿起它备份时，会被告知您已经阅读的部分中的重要部分已经改变，并且确切了解更改内容的唯一方法是重新阅读。不好玩。

Alternatively, this is what changes would look like if you push separate new commits instead:

另外，如果您推送单独的新提交，则更改将是这样的：

You still should rebase from master, but as long as the commits that have already been reviewed haven't meaningfully changed, then your reviewers won't need to look over all of them again. Consider adding a comment after a force-push with a link to the most recently reviewed commit so reviewers can pick up where they left off.

您仍然应该从母版那里重新定基，但是只要已经审阅的提交没有有意义的改变，那么您的审阅者就无需再次检查所有的提交。考虑在强制推送后添加评论，该评论具有指向最近审阅的提交的链接，以便审阅者可以从他们上次中断的地方接听。

更改已获批准！ (Changes approved!)

By the time your PR has been approved, your branch probably now has a few commits that feel a bit messy. I recommend squash-merging and not worrying about it. The purpose for clarity has been achieved. Commit messages from squash-merged PRs will contain links back out to the pull requests where the squashed commits can once again be found.

到您的PR被批准时，您的分支现在可能已经有了一些提交，感觉有些混乱。我建议壁球合并而不用担心。达到澄清的目的。来自壁球合并的PR的提交消息将包含返回到拉取请求的链接，在该请求中可以再次找到被挤压的提交。

I'm not sure if squash merging is still controversial in 2020, in case it still is - React does it ????????‍♂️

我不确定壁球合并是否会在2020年引起争议，万一情况仍然如此-React会这样做吗？

However, perhaps you feel strongly that the commits in a PR are meaningful and significant enough to warrant being merged back into master as separate commits. If that's the case, then now is when you can go to town on rebasing until all the diffs are squashed into the perfect commits before merging without squashing.

但是，也许您强烈感到PR中的提交是有意义且有意义的，足以保证可以作为单独的提交重新合并到master中。如果是这种情况，那么现在是时候您可以重新定级到城镇了，直到所有差异都被压缩成完美的提交，然后再合并而不压缩。

tldr： (tldr:)

each commit in a PR should tell a story of what this commit changes, and ideally also what motivated the change
公关中的每个提交都应该讲述该提交更改的故事，理想情况下还应说明促使更改的原因
rebase aggressively before opening the pull/merge request and requesting reviewers
在打开拉取/合并请求并请求审阅者之前，先进行积极的重新定位
after review begins, stop modifying your branch's commits and push new ones

审查开始后， 停止修改分支的提交并推送新的提交
after approval, squash merge (or selectively squash commits then merge)
批准后，压缩合并(或选择性压缩提交然后合并)

记住 (Keep in mind)

Since the second part of this workflow is heavily informed by how Github handles rebased commits, there may come a day when those concerns are addressed by the platform and this workflow may no longer be required. Until then, please consider optimizing your commits for your reviewers :)

由于该工作流程的第二部分充分了解了Github如何处理基于重新提交的提交，因此平台有一天可能会解决这些问题，并且可能不再需要此工作流程。在此之前，请考虑为审核者优化提交：)