git - 将提交添加到 merge 的分支并开始新的 pull 请求

Question

到目前为止，事情是这样进行的:

1. 在分支 A 上做了一些工作；
2. 在分支 A 上提交了 Pull Request；
3. Pull Request 已 merge 到上游；

现在，我想向分支 A 添加一些工作。是否可以重新打开现有的 Pull Request，以便添加额外的提交，然后再次重新 merge ？如果没有，我怎样才能以干净的方式做到这一点？我想过创建另一个分支并从那个分支打开一个 Pull Request，但它似乎不对，额外的工作应该提交给同一个分支。

Answer 1

快速回答:

不，如果 pull 请求已 merge ，您不能重新打开它，即使可以，也不应该重新打开。

长话短说:

通常，当您的更改为底层代码库增加了一些值(value)(功能性/非功能性)时，您会提交 pull 请求。值(value)可以是简单的日志语句、性能修复或重要功能，但当您的工作不依赖于后续更改时，通常会请求 pull 请求。

想一想，您知道 merge pull 请求是否安全，因为您知道其余代码可能永远不会通过，从而使您的代码库不完整？除非别无选择，否则我个人从不 merge 渐进式分支。我努力记忆我上次这样做是什么时候(我相信我做到了)，但我不记得了。

您可能想要这样做的场景:

• 其他人需要我的更改，我阻止了某人:如果是这种情况，为什么其他同事不从您的存储库中提取更改，或者您甚至可以在远离的功能分支上工作可发布的代码库。

• 您需要更早的反馈:尽快让您的代码得到审查是很好的。如果您需要其他人的意见，请在 pull 请求中声明不应 merge ，并且您可以添加所有您想要的提交，并且人们会在您编写功能代码时提出更改建议。这不是 pull 请求的最正统用法，但为什么不呢？仍然比 merge 一半功能要好。

• 一些规范已经改变，我需要实现它们:它应该是一个新的 pull 请求。你第一次就把工作做对了，所以你做的一切都很好。如果您在项目中采用敏捷方法并且在短时间内进行大量更改，这很好。只要您的第一个 pull 请求被接受并且它是正确的(添加了一些可交付的东西)，您应该可以创建另一个 pull 请求 -> 新要求。

在任何一种情况下，您都可以继续在您的分支上工作，稍后再打开另一个 pull 请求。由于 pull 请求只是来自两个分支之间差异的“补丁请求”，所以你没问题。

如果有其他用例会提示您在您描述的条件下提交 pull 请求，请告诉我。我也很乐意为这些添加推理。

PS:在对目标分支进行更多工作之前，请确保您对目标分支进行了fast-forward 或rebase，这会在以后的 merge 中节省大量工作冲突等