git rebase分支与祖父母

Question

我正在阅读git rebase并正在阅读 - git-scm的文档。

我特别怀疑使用git rebase的onto功能将分支重新绑定到其祖父母（就像上面链接中的情况一样）。
我们假设我们有一个分支/提交结构，如下所示：

C1 <- C2 <- C5 <- C6 [master]
         <- C3 <- C4 <- C10 [server]
               <- C8 <- C9 [client]

现在，我想将client brnach重新定义到master。我检查了client分支并运行git rebase --onto master server client命令。我从这个命令获得的结果（在合并和快速转发主服务器之后）是：

C1 <- C2 <- C5 <- C6 <- C8' <- C9' [master, client]
         <- C3 <- C4 <- C10 [server]

我的疑问是，如果client分支中的更改取决于server分支中的C3提交，该怎么办？ {（1}}分支中的结果代码肯定会在rebase这样的情况下失败。据我所知，不应该将实际结果（在合并和快速转发主客户端之后）如下：

master

有人可以告诉我，我的理解/关注是否错误？

Answer 1

如果你从

开始

C1---C2---C5---C6  master
       \
        C3---C4---C10  server
          \
           C8---C9  client

你希望结果是

C1---C2---C5---C6---C3'---C8'---C9' master, client
                      \
                       C4---C10  server

然后误解是： C3'不能是 C4 的祖先。这不可能发生在这里。

当你这样做时

git rebase --onto master server client

并且，正如您所说，客户端中的更改“依赖于 C3 的更改，您可以解决合并问题

C1---C2---C5---C6  master
       \         \
        \         C8'---C9' client
         \
          C3---C4---C10  server

现在，在合并主和客户端之后，您已准备好重新定义服务器，可能会出现两种情况：

1。如果您在上一次冲突中保留了 C8 中“依赖” C3 的更改，则在解决当前冲突后git会说

  

没有变化 - 您是否忘记使用'git add'？如果什么也没有了   阶段，其他东西已经引入相同的机会   变化;你可能想跳过这个补丁。

     

解决此问题后，请运行“git rebase --continue”。如果   你更喜欢跳过这个补丁，而是运行“git rebase --skip”。至   检查原始分支并停止变基，运行“git rebase   --abort”。

然后你可以做

git rebase --skip

你会得到

C1---C2---C5---C6---C8'---C9'  master, client  
                             \         
                              C4'---C10' server

请注意，没有 C3'，因为这些更改已应用于 C8'。

2。如果您在上一次冲突中未保留 C8 的“依赖” C3 的更改，则解决当前冲突并执行

后

git rebase --continue

你会得到

C1---C2---C5---C6---C8'---C9'  master, client
                             \         
                              C3'---C4'---C10' server

这意味着，当<branch>“取决于”<upstream>上与<newbase>发生冲突时发生变化时，git会为您提供合并解析机制，以便您选择是否现在或以后想要这些改变。

Answer 2

  

我的疑问是，如果客户端分支中的更改取决于服务器分支中的C3提交，该怎么办？主分支中的结果代码肯定会在rebase执行的情况下失败

没错。您已经明确地从提交的历史记录中提交了提交C3。为什么这样？只需git rebase master client。合并server时，git不会再尝试应用C3更改，因为它们不会显示在差异中（或者对这些行的进一步更改会发生冲突）。

编辑：comoits不是“on”分支。历史很重要。分支名称只是轻量级（“一次性使用”在这里不会是一个坏词）引用有助于识别您感兴趣的提交。专注于自己和他们的祖先。