Question

我使用git-svn，我注意到在执行git svn rebase后我必须修复合并冲突时，--ours和--theirs选项的含义为git checkout被颠倒了。也就是说，如果存在冲突并且我想保留来自SVN服务器的版本并丢弃我在本地进行的更改，我必须使用ours，我希望它是{{1} }。

为什么？

示例：

theirs

Answer 1

这似乎与rebase的作用一致。

git svn rebase将从当前HEAD的SVN父级获取修订版本，并根据它修改当前（未提交到SVN）的工作。
git rebase确实提到：
请注意，rebase合并的工作原理是从<upstream>分支顶部的工作分支重放每个提交因此，当发生合并冲突时：
- 据报道，我们这一方面是迄今为止重新推出的系列，以<upstream> 开头，
- ，他们是工作分支 换句话说，双方交换。

git rebase从<upstream>分支顶部的工作分支重放每个提交。

如果你调和这两个定义：

来自SVN的提交是在其上重播本地Git提交的提交。它们是“迄今为止重新定义的系列”的一部分，并被引用为“我们的”（在您的情况下，test.txt文件的内容为bar）
工作分支（包含对SVN未知的Git提交，在您的情况下，具有test.txt内容的baz文件）是“他们的”，并且正在重播每个本地Git提交。 / LI>

换句话说，SVN与否：

“<upstream>”分支（最重要的是重播，这是迄今为止重新提交的提交的一部分）“我们的”。
正在播放的内容（工作分支）是“他们的”。

mnemonic tip的CommaToast好{/ p>

无论HEAD指向的是“我们的”

（git rebase upstream首先检查您想要重新定位的upstream分支：HEAD现在引用upstream - ours 。）

混淆可能来自工作分支在经典git merge中的作用当你合并时：

“工作分支”是包含“到目前为止合并”的内容，被视为“我们的”，
而另一个提交代表什么是 - 没有重播但是 - 合并在工作分支之上，并被视为“他们的”。

正如git rebase手册页提到的那样，在rebase期间合并意味着该方被交换。

另一种说同样的方法是考虑：

我们拥有的是“我们的”，
我们拥有的（并且正在合并或重播）是“他们的”。

合并：

x--x--x--x--x(*) <- current branch B ('*'=HEAD)
    \
     \
      \--y--y--y <- other branch to merge

，我们不会更改当前分支'B'，所以我们所拥有的仍然是我们正在处理的（并且我们从另一个分支合并）

x--x--x--x--x---------o(*)  MERGE, still on branch B
    \       ^        /
     \     ours     /
      \            /
       --y--y--y--/  
               ^
              their

但在rebase 上，我们切换侧面，因为rebase的第一件事就是结帐上游分支！（重播当前提交的内容）

x--x--x--x--x(*) <- current branch B
    \
     \
      \--y--y--y <- upstream branch

git rebase upstream 首先会将B的HEAD更改为上游分支HEAD（因此，将“我们的”和“他们的”切换为以前的“当前”工作分支。）

x--x--x--x--x <- former "current" branch, new "theirs"
    \
     \
      \--y--y--y(*) <- upstream branch with B reset on it,  
                       new "ours", to replay x's on it

，然后rebase将重播“我们的”B分支上的“他们的”提交：

x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
    \
     \
      \--y--y--y--x'--x'--x'(*) <-  branch B with HEAD updated ("ours")
               ^
               |
        upstream branch

git svn rebase 的唯一额外步骤是首先在代表SVN提交的Git远程分支上执行svn“fetch”。
你最初有：

x--x--x--x--x(*) <- current branch B, "ours" for now.
    \                                   
     \
      \--y--y--y <- SVN tracking branch, "theirs for now"

，您首先使用来自SVN的新提交更新SVN跟踪分支

x--x--x--x--x(*) <- current branch B, still "ours", not for long
    \                                   
     \
      \--y--y--y--y'--y' <- SVN tracking branch updated

，然后将当前分支切换到SVN侧（变为“我们的”）

x--x--x--x--x <- for "B", now "their" during the rebase
    \                                   
     \
      \--y--y--y--y'--y'(*) <- SVN tracking branch updated, and branch B: 
                               now "ours" (this is "what we now have")

，在重播您正在进行的提交之前（但现在在该rebase期间是“他们的”）

x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
    \
     \
      \--y--y--y--y'--y'--x'--x'--x'(*) <-  branch B with HEAD updated ("ours")
                      ^
                      |
        upstream SVN tracking branch

为什么“我们的”和“他们的”的含义与git-svn相反

1 个答案: