将提交添加到已合并的分支，并开始一个新的拉取请求。

Question

以下是目前的进展情况：

1. 在A分支上提交了一些工作；
2. 在A分支上提交了一个Pull Request；
3. Pull Request已被合并到上游；

现在，我想在A分支上添加一些工作。是否可以重新打开现有的Pull Request，以便可以添加额外的提交，然后再次合并？如果不行，我该如何以清晰的方式完成此操作？我考虑过创建另一个分支并从那个分支打开一个Pull Request，但这似乎不太对，额外的工作应该提交到同一个分支。

- linkyndy

Answer 1

快速回答：

不，如果合并了，就不能重新打开拉取请求，即使可以，也不应该这样做。

TL;DR：

通常，当您的更改对基础代码库添加一些价值（功能性/非功能性）时，您会提交拉取请求。价值可以是一个简单的日志语句、一个性能修复或一个大型功能，但是当您有一项工作不依赖于后续更改时，通常会请求拉取请求。

想象一下，如果其余的代码可能永远不会通过，导致您的代码库不完整，你是否敢合并拉取请求？我个人从不合并渐进式分支，除非没有其他选择。我试图回想我上次这样做是什么时候（我相信我确实这样做了），但我不记得了。

可能需要执行此操作的情况：

• 其他人需要我的更改，我正在阻塞他们：如果是这种情况，为什么其他同事不从您的仓库中拉取更改，或者您甚至可以在可发布的代码库之外的特性分支上工作。

• 您希望尽早获得反馈：尽快进行代码审查是可以的。如果您希望获得其他人的意见，请在拉取请求上声明不应合并，并且您可以添加所有提交，而当您编写特性时，人们建议更改。这不是拉取请求的最正统用法，但为什么不呢？仍然比合并一半的功能要好。

• 某些规格已更改，我需要实现它们：应该是一个新的拉取请求。第一次做好了工作，所以您做得很好。如果您在项目中采用敏捷方法，并且在短时间内进行大量更改，则可以采用这种方法。只要您的第一个拉取请求被接受并且是正确的（添加可交付内容），则创建另一个拉取请求-》新要求应该没问题。

在任何情况下，您都可以继续在分支上工作，稍后再打开另一个拉取请求。因为拉取请求只是从两个分支之间的差异中提出的“补丁请求”，所以没问题。

请让我知道是否有其他用例会促使您在描述的条件下提交拉取请求。我很乐意为此添加推理。

PS：在进行更多工作之前，请确保使用目标分支fast-forward或rebase，这将为您节省以后在合并冲突等方面的大量工作。

- bitoiu

---

感谢您提供详细的答案。我目前的情况是，一些规格已经改变，我需要在同一个分支上实现它们（因为它与分支指向的同一功能相关）。我要说明的是，这不是一项半途而废的工作，因为已经合并的拉取请求已经完成了它的预期任务。只是还有几件事情需要添加到其中。 - linkyndy

猜想可能并不需要，但我添加了您的用例。开启一个拉取请求是完全可以的。将其视为新的开发。 - bitoiu

听起来还不错，但我可以提交到同一个分支然后在它上面发起新的拉取请求吗？ - linkyndy

重塑即将上游的内容是否安全？ - linkyndy

从你发送最初的拉取请求到意识到需要进行更多更改的时间内，你所跟踪的分支可能已经移动。在这种情况下，我要么执行 fast-forward，要么如果我非常了解我正在修改的内容则执行 git reset --hard <origin>/<branch>。仅当长时间过去并且有未合并的更改时，重新设置基准线才有帮助。你只能重新设置尚未推送的更改，因为重新设置基准线会更改历史记录，但之后可以将其推送。 - bitoiu

尽我所能帮助时，很高兴能有所帮助 ;) - bitoiu