在“ 如何安全地为利润和娱乐而变基”一文中，我介绍了各种技术，以帮助您解决基于一组变更时可能遇到的一些困难。 最重要的是，我没有谈论的是为什么您可能首先要对一组更改进行基础调整，或者最终的结果看起来会是什么样。
首先，为什么
开发人员经常谈论“在区域中”。 当然，在某些复杂的问题上，您需要进入正确的思维模式，并为问题建立良好的心理模型，以便能够有效地解决它们。 这种思维方式与编写良好的提交消息所需要的思维方式有很大的不同，出于稍后我们将讨论的原因，这些信息应该集中在叙述而非技术上。
同时，等到我们完整地完成一项工作，以便我们脱掉代码争执的帽子，戴上提交消息编写帽子，这也是有问题的。 我们可能会遇到不希望的情况，因为我们的工作树上遍布着更新，创建和删除的文件，很难分清为达到最终结果而采取的步骤。 有时甚至是不可能的，因为文件经过了多次迭代更改才得到最终结果。 我们最终完成了一次大规模的提交，可能包含了一些较小的任务，因为既然我们已经做到了，那么很难将所有内容分开。 这对任何需要审查您的代码的人来说都是很糟糕的，并且当您遇到git责任时，您会在2年的时间内为您感到糟糕，并且不得不再次破译混乱以了解您为什么进行了更改。
这两个问题的解决方案是小的承诺，快速的承诺和经常的承诺。 这意味着您每次提交的更改总是很少。 如果您是TDD的一个好起点，那么每个新测试及其关联的代码在每次提交中都会更改。 快速提交意味着我们不会浪费时间，不必担心提交消息的详细信息而失去动力。 我们得到的信息足够多，可以在以后确定提交，如果有一些重要的细节我们可能会忘记的话，也许可以稍作记忆。 在实践中，这通常意味着使用git commit -m "..."语法添加提交。 这迫使您简短。 我通常前缀提交，我以这种方式与特定的字符添加（ —是我一贯的选择），这样我以后就能认出他们。 经常承诺是小的承诺的自然结果。 它应该成为您正常的红绿色TDD周期的一部分。
然后，一旦问题解决了，并且您知道达到解决方案所需的步骤，那么您将处于一个更好的位置，可以将这些步骤重新组织成一组一致的提交。 从这个意义上讲，这就像重构或性能优化。 如果您一开始就尝试这样做，则很可能是重构错误的东西或添加复杂性优化代码，而事实证明这并不是瓶颈。 只有完成工作后，您才能确定改进它的最佳方法。 与准备一组提交类似，只有在您知道所有需要的更改之后，您才能确定将它们构造为一致的提交的最佳方法。
还有其他一些原因，您可能想在合并之前重新构建提交。 当您从事一项工作时，可能会发生很多事情，尤其是工作本身可能会发生变化。 也许这种事情看起来很熟悉……
这里有很多不同的工作正在进行，并且有很多冗余信息。 没有人将所有这些都保留在应用程序的提交日志中。 真正需要保留的是
重要的是，提交日志中必须包含正确的信息粒度。 您要为单独的任务维护单独的提交。 同时，当您试图找出问题的根源时，不必要的提交将成为您的麻烦。
归根结底，提交和重写更改都与效率有关。 目的是减少所有杂物和干扰，同时确保清楚，容易地获得理解变更集所需的所有信息。
现在什么
那么好的提交消息和请求请求是什么样的呢？ 首先要认识到的是，就像代码一样，提交消息被写入一次并被读取多次。 因此，为了确定什么是好的提交消息，您需要考虑您正在为谁写作的受众。 您需要考虑3个主要受众。
您
第一个人是你自己。 在重新编制基准和提交内容的过程中，最有用的部分之一是将所做的更改分类为执行的不同步骤和任务。 在这里，您可以将代码从精通提高为精湛。 您了解为什么提交中的每个单独更改都是必要的吗？ 它能达到什么目的？ 您的更改是否遵循逻辑顺序？ 现在它可以工作了，您可以用更好的方式做同样的事情吗？ 您完成了故事所需的一切了吗？ 你有没有错过任何边缘情况？ 您在这里或那里跳过了测试吗？ 等等等
您应该能够将您的工作分解为清晰，连贯的块，然后应该很容易地描述您要实现的目标以及选择解决方案的原因。
如果您的提交包含以“也已更改……”开头的行，则说明您已将多个更改捆绑到同一提交中
你的团队
您正在寻找的下一组人员是您的团队。 假设您的所有代码都经过了代码审查（而且应该如此），您就可以使团队更容易地理解建议的更改，从而对每个人都更好。 连贯的重点提交并带有解释性消息，这意味着人们可以快速而有效地查看您的代码，而不会陷入试图找出正在发生的事情或为什么需要进行特定更改的困惑。 这意味着您将获得更好的反馈，并且您的队友将更愿意检查您的更改，因为他们会觉得这将是一种建设性的高效利用时间。
您的提交消息应始终专注于更改的叙述，而不是技术细节。 审查代码的任何人都可以从差异中看到技术上的变化。 如果您正在编写“将文件Y中的类X更改为调用方法Z`之类的东西，那您就浪费了所有人的时间，因为差异以一种更精确和有效的方式准确地表明了这一点。 有趣的是为什么您要进行此特定更改。 是否有任何上下文可能导致您选择此解决方案，而不是表面上可能更明显的事物？
您的提交应指导PR读者完成所做的更改。 如果是一组复杂的更改，则应将其分为几个单独的步骤，以便易于遵循，即使这意味着在PR的多次提交中对同一代码进行了修改。 仔细阅读PR上的一组提交消息应该足以解释更改的“内容”和“原因”。 最后的“方法”应通过阅读代码本身来解释。
再过2年或5年或10年
您正在写作的最终读者是您的未来自我。 想象一下，您在git考古学方面颇为精打细算，试图弄清楚某些代码是如何到达特定状态的，而这种提交又出现了。 您想知道什么，以便理解为什么以这种方式进行了这组更改？
请记住，您可能认为很明显的大部分上下文现在可能会变得不那么明显。 目前正在消耗您生命的项目不过是遥远的回忆，您刚刚经历的与同事们敲定各种可能性的痛苦的3个小时的会议将被遗忘，您将需要解释的这一系列内容更改是提交顶部的段落。
在这一点上，您希望看到哪些？
为了有效地为所有这些不同的读者编写代码，您需要花时间并专注于此，作为编写代码本身的一项单独任务。 这是一种非常不同的技能，应该牢记实践，因为它对于开发人员来说与编写代码一样重要。 至少以后可以修复错误代码。 这就是为什么在保持代码编写心态的同时尝试这样做是徒劳且效率低下的原因。
最后要注意的是，在编写提交消息和拉取请求消息时，还需要考虑其他几件事。
提交是存储库的一部分，拉请求不是
如果您想引用以前的更改，可能很想链接到拉取请求。 但是，拉取请求不是git的功能，它们特定于您当时使用的特定git托管提供程序。 如果您更改提供商，则所有与PR的链接现在都将变得无用。 可能有一天，您想尝试使用一种新的超棒git托管服务提供商。 最好不要考虑丢失所有拉取请求信息是一个很大的缺点，或者提交日志现在将包含很多断开的链接。
这有两个含义。 首先是您应该链接到提交而不是在提交消息中拉取请求。 通过SHA引用它们，并让Github，Bitbucket或您使用的任何工具将它们转换为链接。 这样，无论您使用什么工具，它们都将始终起作用。 第二个是所有重要信息都应该在提交消息中，而不是PR消息中。 根据您的提供程序处理合并的方式，您可能最终仍会在合并提交中收到PR消息，但是即使重要信息包含相关的提交，还是要好得多，即使这意味着从提交到提交重复一些信息。 这意味着，如果提交确实在数年内作为git怪的一部分出现，那么人们看到该信息的机会就会大大增加。
拉取请求应说明一个故事
拉取请求应该有一个明确的目标，可以将其描述为叙述。 在许多方面，它都与编写良好敏捷故事的指导方针相呼应。 它应该有明确的动机和受益者。 它应该从业务角度编写，并且应尽可能地非技术性。 有点像书后的摘要。 然后，提交就是该故事中的章节，提交消息应该这样阅读。 每个步骤都是朝着实现拉取请求中列出的总体目标迈出的一步。 最后，差异提供了每章所需的单独代码更改。
正如重复提交消息中的diff中包含的所有信息是多余的一样，重复在拉取请求消息中的提交消息中的信息也是多余的。 拉取请求消息应针对代码审阅者，因为这是它的主要受众（很可能是其唯一的受众）。 它应该简短而不是技术性的。 不要在拉取请求消息上花费很多时间，因为它是所有请求中最短暂的一次，请节省提交消息的精力。
当拉取请求由单个提交组成时，这里是一个例外。 在那种情况下，PR消息应该只是提交消息，大多数提供商无论如何都会默认执行该操作。
因此，在查看了使用git rebase准备我们的请求请求的一些动机以及一些操作示例之后，接下来的问题是如何将其付诸实践。 要获得帮助，请查看如何为获利和享乐安全地进行调整 。
From: https://hackernoon.com/the-poetry-of-pull-requests-c081fbcd0d0