sap 创建请求_如何为您的请求请求创建详细说明

sap 创建请求

许多开发人员都熟悉这种情况，例如“ 此代码片段来自何处以及为什么需要它？ ”。 您必须花时间处理其他同事已经考虑过的细节。 如何使其花费更少的时间？ 为此，请注意为“拉取请求”（称为“ PR”）和“合并请求”（称为“ MR”）编写描述的过程。 本文将重点介绍PR描述的内容，而无需对编码进行任何解释，因为每个项目都有与编码相关的规范和要求。

这是本文涵盖的主题列表：

• 为什么“请求请求”的描述重要而有用？
• 请求请求的有用描述应包含哪些内容？
• 哪个操作有助于编写正确的“拉取请求”描述？

为什么请求请求的描述很重要和有用

首先，让我们尝试理解为什么最好注意PR的描述。

在项目上工作是一条漫长的路，分为几小段。 每个段的开头是任务，步骤是落实，结尾是PR。

当您开始意识到PR是您完成任务的结果时，PR的重要性正在上升。 从表面上看，似乎最重要的部分是提交代码以引入功能，优化最终产品的工作。

但是，还有另一件事-您应用于产品和推理的更改的上下文。  

上下文暗示您对选定的实现方法，选定的工具，遇到的问题和困境的理由。

提供PR的上下文很有用，因为任务本身及其讨论可能不足以了解变更的全部情况。 很好的是，讨论是在问题跟踪器中进行的，或者是口头的或在聊天中进行的，并以简短的结果形式进行了讨论。

如果没有，那么您将必须回答以下问题

“这段代码来自哪里，为什么在这里需要它？”

作为一名审阅者，如果我不得不花更多的时间来理解代码和提交的逻辑，那么在PR审阅期间我不会感到高兴，因为作者没有费心编写适当的描述。 完成编码部分后，更改的作者可以花一些时间来描述PR，而所有内容仍在记忆中。 这样，作者可以节省项目团队的时间和精力。 让我们列出可以从正确描述的PR中受益的项目成员：

• 审阅者不再需要猜测您想要通过更改实现什么。 不再需要花时间问一些问题，例如“为什么选择这种实现方式而不是其他？” 或“ 为什么选择特定的方法或选择某些依赖项？ ”
• 项目同事在查看您的提交时可以找到PR，其中包含所做更改的描述以及与相关讨论相关的任务链接。 最后，这将有助于避免错误，因为如果需要以某种方式更改您的代码，则同事可以找出其逻辑要求并注意相关细节。
• 您无需回答有关已实施更改的其他问题。 在这种情况下，您始终可以参考描述，其中最重要的要点已经阐明。 随着时间的推移，这一点变得越来越重要-因为大约六个月后，将很难记住为什么进行了特定更改。 无论如何，如果通过有意义的描述来备份更改，则无需这样做。

所有这些都得出一个结论：

PR的描述与任务单一样有价值。

在PR的说明中介绍工作结果非常重要且有用，因为它将为将来节省宝贵的时间和精力。

请求请求的有用描述应包含哪些内容

现在，让我们考虑要覆盖的重要部分，以撰写有关PR的有用描述。

标题

从标题开始-它应该反映出变更的本质。 如果有相应的任务或故障单，则PR标题可以与其重叠。 在这种情况下，应添加带有任务编号的前缀。

SLI-001 , SLI -002 - Support for reading input from STDIN
SLI -002 - Bugfix for memory leak when input is supplied via STDIN

标题最好是内容丰富且简短。

相关任务

必须提供与PR相关或将由PR解决的任务和工单。 最好以跟踪器的票证链接的列表的形式提供它们。 在MarkDown中，它看起来是这样的：

## Related tasks
- [SLI-001 ]