Question

我从master分支创建了一个功能分支。之后，功能分支中有一个提交[F1]。

        [F1]            -- Feature Branch
       /
[M1]-[M2]               -- Master Branch

之后，功能分支在主分支中合并，并且在主分支中还有两个提交[M3]和[M4]。

        [F1]                   -- Feature Branch
       /    \
[M1]-[M2]-[F1]-[M3]-[M4]       -- Master Branch

现在我又向功能分支添加了两个提交。

        [F1]-[F2]-[F3]         -- Feature Branch
       /   \
[M1]-[M2]-[F1]-[M3]-[M4]       -- Master Branch

此时，我应该首先将功能分支重新绑定到主分支，以便功能分支更改[M3]和[M4]提交，或者我应该直接进行git合并。

另外，如果我先做git rebase，那么[F1]提交不会在两个分支中：

                       [F1]-[F2]-[F3]       -- Feature Branch
                       /
[M1]-[M2]-[F1]-[M3]-[M4]                    -- Master Branch

Answer 1

你没有必须改变。你可以做合并。重新定义创造了一个非常清晰的历史，但它实际上并不是历史的忠实代表。合并更安全，更直接，并且可以真实地表示开发人员的行为。

从其他版本控制系统来git的人经常不喜欢git的复杂分支和合并历史，因此其中一些人过度使用了rebase功能。这需要额外的努力，它比“合并”更频繁地失败，并且导致错误的历史视图。

我并不是说你永远不应该使用rebase，但根据经验，我会说默认应该是使用“merge”，并且只在你真正想要重写历史时才使用rebase。

为什么rebase有用的一个例子是：假设您正在进行大量的增量提交，并在本地存储库中添加和还原内容。在您推送到全局存储库之前，您决定希望其他团队成员将您的贡献视为更清晰，单一的提交，并删除所有与之无关的内容。然后在推送之前使用“交互式rebase”来整合提交并改进提交消息。

Answer 2

因此，如果，您尚未对 master 进行更改，并且您不介意重写 master 的历史记录，有一种方法可以执行此操作-但是在重新定基础时，您正在重写历史记录，所以make sure you know what you are doing first。

如果确定这是记录历史记录的方向，则应先检出 master 分支，然后将其交互式地变基（git rebase -i）到提交位置，其中< strong>功能被删除（在您的情况下为[M2]）。

在重新设置基准之前，您的历史记录应如下所示（根据您的原始问题）：

        [F1]-[F2]-[F3]         -- Feature Branch
       /   \
[M1]-[M2]-[F1]-[M3]-[M4]       -- Master Branch

启动交互式基础后，您应该看到以下操作：

pick hash_f1 [F1]
pick hash_m3 [M3]
pick hash_m4 [M4]

您将要删除第一次提交，即在提交[F2]和[F3]之前合并功能的内容，以便 master 可以在其中没有 [F1]的情况下重放更改。请注意，您不会丢失[F1]提交，因为它仍属于功能的历史记录。

重新定标应该为您提供以下历史记录：

        [F1]-[F2]-[F3]         -- Feature Branch
       /
[M1]-[M2]-[M3]-[M4]            -- Master Branch

母版具有所有M个提交，而功能具有所有F个提交，但仍从[M2]中删除。从那里进行简单的合并，即可将功能恢复为主版本：

git merge --no-ff feature

瞧瞧–您拥有想要的东西：

        [F1]-[F2]-[F3]         -- Feature Branch
       /             \
[M1]-[M2]-[M3]-[M4]-[F*]       -- Master Branch

同样，请务必小心，这是您要执行的操作，因为重写历史记录可能很危险。也就是说，在本地进行绝对值得。

此外，此过程可以扩展到任何ref，而不仅仅是功能部件和master分支，因此在其他情况下，这样做可能更有意义。我认为，像 master 这样的稳定分支通常应该无法重写其历史记录，但是每个Git环境和工作流都是不同的，因此实际上没有任何规则无法重写。

Answer 3

正如所说，不需要变基。

问题的最后部分：

“如果我先做git rebase，那么[F1]提交不会在两个分支中”

如果你继续使用rebase，那么

F1提交就会被忽略。

如果上游分支已经包含您所做的更改（例如，因为您邮寄了上游应用的补丁），那么将跳过该提交。例如，在以下历史记录中运行git rebase master（其中A'和A引入相同的更改集，但具有不同的提交者信息）：

      A---B---C topic
     /
D---E---A'---F master

将导致：

               B'---C' topic
              /
D---E---A'---F master