根据OP在Ryen Nelsen的回答中发布的评论:
...主/开发分离并不是真正的问题 - 通常我遵循gitflow范例。我感兴趣的是 - 如何仅为feature-X发送pull-request,考虑到我的develop比原始存储库要先进得多?我使用cherry-picking,但这是最好的方法吗?
我想问一下,你所说的develop分支比原始存储库(我从现在开始称之为master分支)要先进得多是什么意思?你的develop分支中还有其他东西吗?
听起来你正在完成重要的开发工作,但短期内不会进入master。在这种情况下,为每个将提交给master的Pull Request/issue/enhancement创建一个单独的功能分支。
如果你小心谨慎,你可以最小化你的各种特性分支之间的差异,包括引用中讨论的相互依赖关系。例如,假设你正在维护develop
并尝试向master
提交fea1
和fea2
的拉取请求。
设置两个特性分支,从主分支
创建 并从开发分支
使用樱桃选取或变基 到
fea1
和
fea2
直到它们拥有您需要的来自现有
develop
更改的基础。
如果存在相互依赖关系,这意味着您将在每个特性分支上樱桃选取一些相同的提交,或者最终会开发新代码,在两个特性分支之间合并或变基。
为
fea1
和
fea2
开发新修复程序,并根据需要合并(或重新基于/压缩)到
develop
。在这种情况下进行合并,因为您是唯一在此repo中进行开发的人,所以很简单-您一次只能处理
develop
、
fea1
或
fea2
中的一个,因此合并实际上将处理您必须解决的冲突。
一旦准备好了拉取请求,您可以将fea1
和fea2
保留在它们自己的分支中,并继续单独在develop
上工作。同时,随着拉取请求获得反馈,您始终可以检出fea1
或fea2
并更新它们,可能需要从fea1
合并到fea2
或反之亦然,并且还可能需要将新的提交合并回develop以使其保持最新状态。
一旦PR被接受,您可以清理您存储库中相应的私有功能分支上需要的任何内容,并确保对其他分支和develop
的任何最终合并都已完成。
然后你可以删除功能分支,但个人而言,我会标记最后一次提交,以便将来需要时可以回到它,然后删除分支引用。这样,您可以返回到一个提交,该提交可能比develop
更接近master
,尽管取决于经过了多长时间,也许不是-至少您会有选择。例如,如果您的PR中存在缺陷,并且新问题已打开,您可以快速解决,但其他人需要更长时间。