git rebase已经合并了分支？ [英] git rebase already merged branch?

问题描述

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

  [F1]  - 功能分支
 / 
 [M1]  -  [M2]  - 主分支
  

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

  [F1]  - 功能分支
 / \ 
 [M1]  -  [M2]  - [F1]  -  [M3]  -  [M4]  - 主分支
  

现在我增加了两个提交

  [F1]  -  [F2]  -  [F3]  - 功能分支
 / \ 
 [M1]  -  [M2]  -  [F1]  -  [M3]  -  [M4]  - 主分支
  

此时，我应该首先将特征分支重新转换为主分支，以便特征分支具有[M3]和[M4]提交的更改，或者我应该直接进行git合并。

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

<$ p $ [F1] - [F2] - [F3] - 功能分支
/
[M1] - [M2] - [F1] - [M3] - [M4 ] - Master Branch

解决方案

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

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

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

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

I created a feature branch from master branch. After that there is a commit [F1] from feature branch.

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

After that, feature branch is merged in master branch, and there are two more commits [M3] and [M4] in master branch.

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

Now I added two more commits to feature branch.

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

At this time, should I first rebase the feature branch to master branch, so that feature branch has change of [M3] and [M4] commits, or should I do the git merge directly.

Also, if I do git rebase first, won't the [F1] commit be in both the branches:

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

解决方案

You don't have to rebase. You can just do the merge. Rebasing creates a very clear history, but it is actually not a faithful representation of the history. Merging is safer, it is more straightforward, and it results in a true representation of the actions of developers.

People who come to git from other version control systems often dislike the complicated branching and merging history of git, so some of them are overusing the rebase feature. This takes extra effort, it fails more often than "merge", and it results in a false view of the history.

I'm not saying you should never use rebase, but as a rule of thumb I'd say the default should be to use "merge", and use rebase only when you really want to rewrite history.

One example of why rebase is useful is: Suppose you're making lots of incremental commits, and adding and reverting stuff on your local repository. Before you push to the global repository, you decide you want the other team members to see your contribution as a cleaner, single commit, taking out everything that's irrelevant. Then you use "interactive rebase" to consolidate your commits and improve the commit message, before pushing.

这篇关于git rebase已经合并了分支？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！