到目前为止，情况如下：
现在，我想向分支A添加一些工作。是否可以重新打开现有的Pull Request，以便可以添加额外的提交，然后重新合并？如果没有，我该怎么做呢？我曾考虑过创建另一个分支并从该分支中打开“拉取请求”，但这似乎并不正确，应该将更多工作提交给同一分支。
快速回答：
不，如果合并了合并请求，则无法重新打开该请求，如果可以，则无论如何都不可以。
TL; DR：
通常，当您的更改为基础代码库增加一些值（功能/非功能）时，您会提交拉取请求。值可以是简单的日志语句，性能修正或重要功能，但是当您的工作不依赖于后续更改时，通常会请求拉取请求。
考虑一下，您知道合并其余的代码可能永远无法通过，从而使您的代码库不完整，合并合并请求是否安全？除非我别无选择，否则我个人从不合并累进分支。我想回想一下我上次这样做的时间（并且我相信我曾经这样做过），但我不记得了。
您可能需要这样做的方案：
有人需要我的更改，我正在阻止某人：如果是这种情况，为什么其他同事不从您的存储库中提取更改，或者甚至可以在功能分支之外使用可发布的代码库。
您需要较早的反馈：最好尽快检查您的代码。如果需要其他人的输入，请在拉取请求中声明不应将其合并，然后可以添加所需的所有提交，并且人们在编码功能时会建议进行更改。这不是拉取请求中最传统的用法，但是为什么不呢？仍然比合并一半功能更好。
一些规格已更改，我需要实现它们：它应该是新的请求。您是第一次正确完成工作，所以一切都很好。如果您在项目中采用敏捷方法，并且在短时间内进行了很多更改，那么这很好。只要您的第一个拉取请求被接受并且是正确的（添加了可交付的内容），您就可以创建另一个拉取请求->新要求。
无论哪种情况，您都可以继续在分支上工作，以后再打开另一个拉取请求。由于拉取请求只是两个分支之间差异的“补丁请求”，因此可以。
请让我知道是否还有另一个用例会提示您在您描述的条件下提交拉取请求。我也很乐意为这些添加推理。
PS：在进行更多工作之前，请确保您fast-forward或rebase与您的目标分支合作，这将在以后合并冲突等方面为您节省很多工作。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句