我知道这两个选项看起来都一样。

出于审美原因，为同一问题创建不同的分支（如果你真的继续它而不是创建新的相关问题）可能并不可取：不要为一个存储库中的每个功能保留多个分支。

另一方面，如果自从接受拉取请求后此分支中没有任何更改，那么在合并调整时，如果develop在这些调整之前发生了其他事情，则很有可能会发生合并冲突。

如果你的存储库是“保守地”维护的（没有不断的变基以摆脱纠结的提交树）......

可以组合！

你可以合并develop进去feature/5131（没错，反方向！），然后像往常一样继续在同一个分支工作。

因此，该功能的工作将在同一分支中继续进行，但与此同时，与完成开始时已知的更改的冲突将是不可能的，因为工作将从最新的状态和已解决的冲突（如果有）开始。

如果任务的解释已经改变，你需要完成、重做，特别是如果你需要修复已接受的拉取请求中的功能，首先，你需要恢复已接受的请求。

$git revert #merge-hash -m 1

这样，您将保护团队的其他开发人员免受使用不正确代码的可能性。

然后你需要合并到功能分支，然后恢复所谓的提交。双重回归。需要双重还原，以便您的更改在公共开发分支中定义。没有它，git 将无法添加还原的更改。完成/重做/修复任务的代码后，您可以再次运行拉取请求。

您可以在此处阅读有关双重还原和类似情况的更多信息。