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