git rebase已经合并分支？

我从主分支创建了一个功能分支。之后，从功能分支中提交[F1]。git rebase已经合并分支？

 [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变基第一，不会在[F1]承诺在两个分支：

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

2016-01-19 manish

您不必变基。你可以做合并。重新激活创造了一个非常明确的历史，但它实际上不是历史的忠实代表。合并更安全，更直接，并且能够真实反映开发人员的行为。

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

我并不是说你永远不应该使用rebase，但作为一个经验法则，我会说默认应该使用“merge”，并且只有当你真的想重写历史时才使用rebase。

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

2016-01-19 10:00:10

这根本不是问题。我了解你的观点，我不同意，但这只是你的观点。它避免了回答问题而不是回答问题。 –

嗯，我认为它直接回答了原文中的一个问题：“我应该首先将特征分支重定位到主分支，以便特征分支具有[M3]和[M4]提交的更改，或者我应该执行git直接合并？“。我同意你的看法，它不回答第二个问题。 –

正确地说，不需要rebase。

有关问题的最后一部分：

“如果我git的变基第一，不会在[F1]承诺在两个分支”

F1承诺会被中省略，如果你继续进行rebase。

如果上游分支已经包含所做的改变（例如，因为你邮寄其上游施加贴片），则该承诺将被跳过。例如，运行git变基上的以下历史主（其中A”和A引入同一组的变化的，但具有不同的提交者信息）：

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

将导致：

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

2017-10-05 08:47:33 nikosstais

回答