Git 工作流，在级联中重新设置 2 个功能分支

Question

我正在尝试为特定情况找到一个好的 git 工作流程。

一般情况下工作正常：我有一个主分支，我从中创建了一个功能分支。我经常将功能变基到 master 上，一旦功能准备就绪，我就会在 master 上执行拉取请求。

            master
            v
*---*---*---*
         \
          *--*
             ^
             feature

现在有时候，一个大功能需要几个开发人员。我们还是从master创建一个feature分支，然后从feature创建feature1和feature2。 feature1、feature2 和 feature 之间的工作流程与一般情况下 feature 和 master 之间的工作流程相同（抱歉，我的 git 绘图可能有点难看，不习惯这样做）。

            master      feature2
            v           v
*---*---*---*       *---*
         \         /
          *---*---*
              ^    \
        feature     *---*
                    ^
                    feature1

在理想情况下，一旦 feature1 和 feature2 完成，我们将 PR/merge 它们变成 feature，然后将 feature 变基到 master，最后 merge/do 将 feature PR 到 master。

但我们可能需要在此之前将功能变基到 master 上，以获得一些新的更改或者只是不必一次获得太多更改。我们可能会修复冲突（由假设的 feature3 引起，或者可能是因为我们已经从 feature1 合并到 feature，即使 feature1 还没有完全完成）。

Feature1 和 feature2 还没有完成，我们需要将它们 rebase 到 feature 上。并且会出现与我们将 feature 重新定位到 master 时非常相似的冲突。我最近听说 git rerere 但我尝试了一个非常简单的例子，我遇到了非常相似但不完全相同的冲突，所以我每次都必须解决它们。我并不完全理解它是如何工作的，所以也许我做错了什么。

另一种解决方案是不将 feature 变基到 master 上，而是将 master 合并到 feature 中。因此，如果在那里解决了冲突，当我将 feature1 变基到 feature 时，它们将不再出现。这会污染功能的历史记录，但我想我可以在将功能合并到 master 之前进行交互式 rebase 来压缩不需要的合并提交。

所以基本上我的问题是：对于我想要实现的目标，有什么好的做法吗？我的同事倾向于合并所有东西，但我想要更干净的东西，而且我可以从头到尾理解。我可以继续变基并避免与 git rerere 再次发生冲突吗？因为在这种情况下它是一个 public/shared 分支，所以它可以变基功能吗？在我决定将其合并到 master 之前，我是否应该不关心功能的状态，然后才进行一些重构，同时将 master 合并到其中？将功能变基到 master 上而不是将 master 合并到 master 上太麻烦了？

Answer 1

虽然您通常不会合并到另一个分支，但在这种特定情况下，这将是更实用的选择（如“merge master to a branch”）

为其他分支使用的分支变基变得非常棘手，rebase 操作最好保留给其他分支不使用的分支。

Git 工作流，在级联中重新设置 2 个功能分支

Git workflow, rebase in cascade with 2 features branches

git

git-rebase