到目前为止事情已经过去了：
现在，我想向分支A添加一些工作。是否可以重新打开现有的Pull请求，以便可以添加额外的提交，然后再次重新合并？如果没有，我怎么能以干净的方式做到这一点？我想创建另一个分支并从那个分区打开一个Pull Request，但它看起来不对，应该将额外的工作提交到同一个分支。
答案 0 :(得分：5)
快速回答：
不，如果合并了拉动请求，你就无法重新打开拉动请求，如果可能的话，你也不应该这样做。
<强> TL; DR：
通常，当您的更改为底层代码库添加一些值（功能/非功能）时，您会提交一个pull请求。值可以是简单的日志语句，性能修复或大功能，但当您有一项不依赖于后续更改的工作时，通常会请求拉取请求。
想一想，你觉得合并拉取请求是否安全，知道其余代码可能永远不会通过，让代码库不完整？除非我别无选择，否则我个人从不合并渐进式分支。我想记住我最后一次做这件事（我相信我做过），但我不记得了。
您可能希望这样做的情景：
其他人需要我的更改，我阻止某人：如果是这种情况，为什么其他同事不从您的回购中提取更改，或者您甚至可以在远离可释放的代码库。
您需要更早的反馈：您可以尽快审核您的代码。如果您想要其他人的输入，请在拉取请求中说明它不应该合并，并且您可以添加所需的所有提交，并且人们在编写功能时会建议更改。这不是拉动请求最正统的用法，但为什么不呢？仍然比合并半个功能更好。
有些规格已经改变，我需要实现它们：它应该是一个新的拉取请求。你第一次就做好了你的工作，所以你做的一切都很好。如果您在项目中采用敏捷方法，并且在很短的时间间隔内进行了大量更改，那么这很好。只要您的第一个拉取请求被接受并且它是正确的（添加了可交付的东西），您应该可以创建另一个拉取请求 - ＆gt;新要求。
在任何一种情况下，您都可以继续处理分支并稍后再打开另一个请求。由于拉取请求只是来自两个分支之间差异的“补丁请求”，您可以。
如果有另一个用例会提示您在所描述的条件下提交拉取请求，请告诉我。我也很乐意为这些人添加推理。
PS：在对其进行更多工作之前，请确保fast-forward或rebase与目标分支一起使用，它将在以后的合并冲突等方面为您节省大量工作。