Question

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

然而其他人正在进行变基，我想尝试一下。我已经阅读了它（例如here），虽然我明白了，但有点让我感到困惑。

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

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

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

Answer 1

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

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

过了一段时间，其他人已经在master上完成了工作，以便历史记录成为

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

将feature重新定位到master的唯一方法就是在您创建feature分支时更改：

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

通过定期执行此操作，您可以解决任何潜在的合并冲突，然后才能堆积起来。如果定期将master合并到功能中，最终会在feature中进行大量的虚假合并提交。使用rebase，你可以避免它们，当你最初从feature分支master时，你会看不到它。请注意，如果尚未已经推送feature，您应该只进行重新定位;一旦你这样做，你就与其他人分享了feature的历史，不应该改变它。

Answer 2

要定期将功能分支重新定位到目标分支的当前状态（我假设在此方案中为origin / master），只需从功能分支执行此操作：

git fetch origin            # Updates origin/master
git rebase origin/master    # Rebases current branch onto origin/master

等效替代方案：

git pull --rebase origin master

通过这样做，您将使您的功能分支与您的原始/主分支保持同步。您可以将其合并到本地主服务器并推送到origin / master 或，您只需将已更新的功能分支推送到远程存储库，然后执行pull请求即可。这实际上取决于你的git工作流程。

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

2 个答案: