Question

在将master重新定位到分支时，我在分支上遇到了一些冲突。

情景是：

分支关闭master，进行一些更改，提交所述更改。 Checkout master，进行一些更改，提交所述更改，checkout branch-1。试着改变主人 - 冲突..

现在我有其他开发人员以类似的方式工作。

Master会在包括网络服务器在内的所有回购邮件上保持同步，我不希望更改主人的历史记录。

如果我解决了与过去相冲突的rebase冲突，如果我签出主人并将其与分支合并 - 将更改主人的历史记录 - 或者这些冲突解决方案是否应用于所有合并的工作之上？

Answer 1

想象一下你目前的情况：

- A - B - C - D
   \          ^
    - X - Y   master
          ^
          branch1

运行git checkout branch1; git rebase master将从 branch1 移动提交，以便它们应用于 master 分支之上：

              master
              v
- A - B - C - D
               \      
                - X - Y 
                      ^
                      branch1

这不会改变 master ，但会以两种方式更改 branch1 ：

通过将提交X的父级从A更改为D，您将更改提交X的ID，事实上就Git而言，它现在是一个全新的提交（由于X有一个新的ID，Y有一个新的父级，所以Y也会得到一个新的ID，依此类推，如果分支上有更多的提交）。
您需要做的任何冲突解决都将改变提交的内容。

如果您已经将 branch1 推送到远程存储库，那么重新定义它是一个非常糟糕的主意;改变已经分享的历史只会导致问题。

假设您没有推送 branch1 ，则可以将其合并到 master （使用git checkout master; git merge branch1），这将导致 master < / em>被快速转发以提交Y。这为您提供了整洁的线性历史记录，无需更改 master ：

- A - B - C - D - X - Y ^ branch1 AND master

如果您已经推送 branch1 ，那么您应该避免使用rebase并使用合并（使用git checkout master; git merge branch1），这不会改变其中任何一个的历史记录，但会创建一个主分支上的新提交（在此图中标记为M）：

- A - B - C - D - M \ / ^ - X - Y - - master ^ branch1

Answer 2

如果您进行rebase，无论您重新绑定哪个分支，您都将更改存储库的历史记录。这个想法是，当其他开发人员在你推动之后拉主人（来自说起源）时，他们的回购也将是最新的。

要明确：合并冲突而变基不会改变主人的历史。作为合并方法重新定位将。

如果您不想更改master的历史记录，则不能将其作为合并方法进行rebase。默认的git合并行为应该适合你，冲突与否。

git checkout master
git merge branch-1

Git Rebase主要冲突

2 个答案: