1

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

场景是：

从 master 分支，进行一些更改，提交所说的更改。结帐大师，进行一些更改，提交所说的更改，结帐分支1。尝试 rebase master - 冲突..

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

Master 在包括网络服务器在内的所有 repo 上保持同步，我不希望 master 的历史记录被更改。

如果我解决了与过去某个点发生冲突的 rebase 冲突，如果我签出 master 并将其与分支合并 - 是否会更改 master 历史记录 - 或者这些冲突解决方案是否会应用于所有正在合并的工作之上？

4

2 回答 2

7

想象一下你现在的情况：

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

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

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

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

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

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

假设你没有推送branch1，你可以将它合并到master（with git checkout master; git merge branch1），这将导致master被快进到 commit Y。这为您提供了整洁的线性历史，而无需更改master：

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

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

- A - B - C - D - M
   \            / ^
    - X - Y - -   master
          ^
          branch1
于 2012-05-26T10:52:15.920 回答
1

如果你变基，无论你变基到哪个分支，你都在改变你的存储库的历史。这个想法是，当其他开发人员在你推送之后拉出 master（比如起源）时，他们的 repos 也将是最新的。

需要明确的是：在 rebase 时合并冲突不会改变 master 的历史。将变基作为合并方法。

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

git checkout master
git merge branch-1
于 2012-05-25T15:31:38.010 回答