Question

我正在使用git-svn。我试着做一个git svn rebase。一切都破了。我在reflog中找到了旧的repo状态，并试图以最安全的方式进行。现在我的回购看起来像这样：

更新：我在rebase之前进行了合并

... -- A (origin/branchA) -- B -- C -- D (BranchA,HEAD)
                                 /
                                /
... -- E (origin/trunk,Trunk) -- ...

我做了以下

branch BranchA-Fix origin/branchA

回购看起来像这样

... -- A (origin/branchA,BranchA-Fix) -- B -- C -- D (BranchA,HEAD)
                                _____________/
                               /
   -- E (origin/trunk,Trunk) -- ...

然后我尝试将我的工作移到一边，这样我就不会有任何冲突试图做一个git svn rebase

git rebase BranchA-Fix

首先，倒带头重播你的工作......应用：其脚本次要更新使用索引信息重建基础树...

...

合并...自动合并硬件/ d3_script.ii CONFLICT（内容）：合并   硬件冲突/ d3_script.ii无法合并更改。   修补程序在0001处失败其脚本次要更新修补程序的副本   失败的原因在于：
  /cygdrive/SOME_DIRECTORY/.git/rebase-apply/patch

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

发生什么事了？为什么在地球上重新定位直接祖先会导致任何类型的合并冲突？如何在不导致合并错误的情况下继续使用svn更新？

Answer 1

这种冲突非常令人期待，代表了混合合并和重组的众所周知的问题。 git-svn特别严重。

基本上你要求git重播BranchA-Fix所有提交给你当前HEAD（BranchA）而不是BranchA-Fix的提交。这有效地意味着整个行李箱从一开始就形成了其余部分。

您可以通过git log HEAD --not BranchA-Fix直观地看到这一点，或者对您的案例更具说明性 - 尝试以交互模式重复您的rebase：git rebase --interactive BranchA-Fix

一般来说，对于具有双向同步的git-svn，强烈建议避免合并并完全切换到rebase工作流程。理由 - git svn dcommit的变形性质。

你当前情况的解决方案取决于分支关系的细节，保持历史（非压缩提交）的git-only分支的必要性和rebase分支的能力（你的情况中的最后一个似乎是没问题）。

Answer 2

除了避免完全合并之外，另一种解决方案是使用混合重置而不是重新设置基准。

基本上，而不是运行：

git rebase BranchA-Fix

您可以改为：

git reset BranchA-Fix
[... stage changes for B...]
git commit -m "B"
[... stage changes for C and E...]
git commit -m "E"
[... stage changes for D...]
git commit -m "D"

...或者，更有效的是，如果您打算将其压榨：

git reset BranchA-Fix
git commit -am "MyNewMessage"

为什么重新定位到祖先会导致合并冲突

2 个答案: