使用git-flow,如何将rebase工作到混合中

我是变革的全新品牌.我已经习惯了git-flow方法,我分支了我们的main/develop分支,做我的工作,在github上打开一个pull请求,然后它就被合并了,我们继续前进.效果很好.

然而其他人正在进行变基,我想尝试一下.我已经阅读了它(例如这里),当我明白这个想法时,有点让我感到困惑.

在git-flow中,当我对分支进行更改时,我将该分支推送到服务器并打开pull请求.在一个rebase中,根据上面的链接,我被告知Periodically rebase your feature branch onto the current state of the destination branch......

......如果我这样做,那我该怎么推到github？我所依据的分支,(develop在我的情况下)？作为一个对我来说感到奇怪的git-flow家伙,但也许那是因为我不习惯它.

如果还有其他关于如何从git-flow转变为变革的想法,我也很高兴听到它.

假设你的功能分支看起来像这样

* -- * -- A (master)
           \
            * -- * -- * (feature)

过了一段时间,其他人已经完成了工作,master以便历史成为现实

* -- * -- A -- B -- C -- D -- E (master)
           \
            * -- * -- * (feature)

该基础重建的唯一的事情feature上master做的是当它出现您所创建的改变feature分支:

* -- * -- A -- B -- C -- D -- E (master)
                               \
                                * -- * -- * (feature)

通过定期执行此操作,您可以在堆积之前解决任何潜在的合并冲突.如果定期将master合并到功能中,最终会出现大量的虚假合并提交feature.有了底垫中,你躲得过,与价格是,你看不见,当你最初支的feature距离master.请记住,如果你还没有推动,你应该只改变feature; 一旦你这样做,你就feature与他人分享了历史,不应该改变它.