以下是目前的进展情况:
- 在A分支上提交了一些工作;
- 在A分支上提交了一个Pull Request;
- Pull Request已被合并到上游;
现在,我想在A分支上添加一些工作。是否可以重新打开现有的Pull Request,以便可以添加额外的提交,然后再次合并?如果不行,我该如何以清晰的方式完成此操作?我考虑过创建另一个分支并从那个分支打开一个Pull Request,但这似乎不太对,额外的工作应该提交到同一个分支。
以下是目前的进展情况:
现在,我想在A分支上添加一些工作。是否可以重新打开现有的Pull Request,以便可以添加额外的提交,然后再次合并?如果不行,我该如何以清晰的方式完成此操作?我考虑过创建另一个分支并从那个分支打开一个Pull Request,但这似乎不太对,额外的工作应该提交到同一个分支。
快速回答:
不,如果合并了,就不能重新打开拉取请求,即使可以,也不应该这样做。
TL;DR:
通常,当您的更改对基础代码库添加一些价值(功能性/非功能性)时,您会提交拉取请求。价值可以是一个简单的日志语句、一个性能修复或一个大型功能,但是当您有一项工作不依赖于后续更改时,通常会请求拉取请求。
想象一下,如果其余的代码可能永远不会通过,导致您的代码库不完整,你是否敢合并拉取请求?我个人从不合并渐进式分支,除非没有其他选择。我试图回想我上次这样做是什么时候(我相信我确实这样做了),但我不记得了。
可能需要执行此操作的情况:
其他人需要我的更改,我正在阻塞他们:如果是这种情况,为什么其他同事不从您的仓库中拉取更改,或者您甚至可以在可发布的代码库之外的特性分支上工作。
您希望尽早获得反馈:尽快进行代码审查是可以的。如果您希望获得其他人的意见,请在拉取请求上声明不应合并,并且您可以添加所有提交,而当您编写特性时,人们建议更改。这不是拉取请求的最正统用法,但为什么不呢?仍然比合并一半的功能要好。
某些规格已更改,我需要实现它们:应该是一个新的拉取请求。第一次做好了工作,所以您做得很好。如果您在项目中采用敏捷方法,并且在短时间内进行大量更改,则可以采用这种方法。只要您的第一个拉取请求被接受并且是正确的(添加可交付内容),则创建另一个拉取请求-》新要求应该没问题。
在任何情况下,您都可以继续在分支上工作,稍后再打开另一个拉取请求。因为拉取请求只是从两个分支之间的差异中提出的“补丁请求”,所以没问题。
请让我知道是否有其他用例会促使您在描述的条件下提交拉取请求。我很乐意为此添加推理。
PS:在进行更多工作之前,请确保使用目标分支fast-forward
或rebase
,这将为您节省以后在合并冲突等方面的大量工作。
fast-forward
,要么如果我非常了解我正在修改的内容则执行git reset --hard <origin>/<branch>
。仅当长时间过去并且有未合并的更改时,重新设置基准线才有帮助。你只能重新设置尚未推送的更改,因为重新设置基准线会更改历史记录,但之后可以将其推送。 - bitoiu