解决Git Svn冲突

Question

解决Git Svn冲突

10

我正在使用Git-Svn与工作中的Svn仓库交互，但似乎找不到有效地解决冲突的方法。我已经阅读了其他关于这个主题的问题，但显然我需要更多基础的东西，因为我总是陷入某种无限循环中。我进行rebase，使用mergetool（meld）来解决冲突，当我完成所有这些操作之后，尝试执行dcommit时，会出现合并冲突提交错误。

我知道这感觉像一个重复的问题，但是沮丧让我再次提问，带上一些非常具体的细节，以便有人可以告诉我我的过程究竟错在哪里。

我的设置:

我有一个远程分支（svn/trunk），一个本地分支（trunk）和另一个我通常在其中工作的本地分支（working-trunk）。trunk是从svn/trunk检出的，而working-trunk是从trunk检出的。

这就是我一直在做的:

在我的trunk上，运行git svn rebase（返回冲突）
git mergetool
[解决那个文件的冲突]
保存meld中合并的文件并关闭meld。
git add .
git rebase --continue
[重复上述步骤]
如果我收到一个询问我是否使用git add的消息，我就运行git rebase --skip

当我到达所有报告的更改的末尾时，一切都停止了，也许此时我不确定该怎么做。Git显示没有要提交的内容，而且我似乎又回到了trunk。然后，Git允许我进行dcommit，但是如果我紧接着尝试rebase，我会再次重新解决刚刚解决的冲突。

这里显然有一个关键的部分我不明白，但我只是看不到它，这导致了很多问题和挫败感。在Git中合并可能很容易，但我发现情况并非如此。

谢谢。

更新： 我想简单介绍一下我的工作流程，以防这可能是问题的一部分（或全部）。

首先，在使用 svn/ 前缀克隆我的存储库后，我拥有自己的 svn/trunk 远程分支。鉴于此：

我使用 git co -b trunk svn/trunk 将我的远程分支检出到本地分支。
我使用 git co -b working-trunk 创建一个工作分支，用于创建更多的分离度，以便我的本地 trunk 可以始终镜像我的远程主干。
我删除默认的 master 分支（在使用 svn 时，我发现以“trunk”而不是“master”来思考更容易）。

一旦我拥有所有分支，我的典型工作流程如下：

在 working-trunk 上，我进行更改并提交它们。
我使用 git co trunk 并执行 git svn rebase。
假设代码已被重新基于，则我使用 git rebase working-trunk。
git co working-trunk
git merge trunk
git rebase trunk
git co trunk
git merge working-trunk
git svn dcommit

我知道这是很多步骤，但这就是这里和其他地方推荐的。我的致命缺陷可能在这个过程中的某个地方吗？

再次感谢。

- Rob Wilkerson

1

你选择的答案（Jistin的）解决了问题吗？ - inger

7个回答

4

我最近遇到了同样的问题（git svn rebase 返回冲突）。我发现这个问题在我的工作流程中。以下是我/您应该遵循的工作流程：

git svn rebase # put all the new commits on top

git svn dcommit # push the new commits to svn (will rewrite each commit message to add the svn tag)

git pull # merge the conflicts due to the commit messages

git push # push the synchronized version to the remote git server

每当我在dcommit之后忘记合并历史记录，如果我进行新的提交，就会出现新的（虚假）冲突。要解决这个问题，您可以按照上述方法进行操作，或者如果您遇到与我完全相同的问题，也可以通过以下方法自动解决：

git svn rebase --strategy ours

- user1448926

事实上，我在使用“ours”策略时遇到了一些问题。它似乎忽略了新的提交。现在，我只需运行“git rebase --skip”，直到它停止抱怨。 - user1448926

1

你可能会发现SubGit的方法更容易：

在服务器端将SubGit安装到Subversion存储库中
使用git而不是git-svn将更改发送到SVN存储库*

SubGit安装会创建一个SVN存储库的Git副本。将其克隆到本地存储库；创建任何分支并将它们推送到远程Git存储库，SubGit会自动将这些分支转换为SVN。

有关更多详细信息，请参阅SubGit文档和git-svn比较。

* 适用于任何Git客户端。

- vadishev

0

我建议只在本地的trunk和远程的trunk之间使用git-svn。在本地的trunk和本地的mytrunk之间，只使用标准的git功能。你可以尝试这样的工作流程：

[SVN]---git-svn---[trunk]---branch---[mytrunk]

要合并，请切换到trunk并执行以下操作：

git svn rebase

这将从远程拉取更改并将其与主干合并。然后，切换到我的主干并执行：

git rebase

这将从trunk中拉取更改并将其与mytrunk合并。我认为它应该可以工作。否则，只需git-clone本地trunk并在克隆上工作即可。

- sybreon

如果我理解正确的话，那听起来就像是我所做的。我会在我的原始问题中更新我的工作流程。 - Rob Wilkerson

0

我在使用推荐的工作流程时遇到了这个问题，所以我认为我们在这里缺少一个答案。

以下是我遇到这种情况的过程。

我通过git svn在Apache基础设施上拥有一个git repo。

我有一个本地分支。

我尝试按照以下步骤进行：

1）rebase trunk。 2）将trunk合并到私有分支中。 3）进行工作。 4）rebase trunk。 5）将私有分支合并到trunk中。 6）dcommit。

然而，我搞砸了，我忘记将私有分支的更改推送到trunk。然后我对我的私有分支进行了一系列其他更改，并最终陷入了完全无关的冲突循环中。我最后一次推送的更改是注释掉一行代码。当我删除被忽略的更改中的那一行时，它产生了无法解决的冲突。最终我使用了--skip选项来解决它。

- bmargulies

0

我尝试了一下，强制引发了一个（虽然很小的）冲突，在执行git svn dcommit之后，我就没有遇到过其他冲突了。一个区别是我没有收到有关git add的消息。你的团队可能只是提交了很多与你的工作冲突的提交吗？这似乎不太可能，但这似乎是最简单的解释。

你可以在另一个位置再次获取repo，并测试是否可以推送非冲突性更改，以确保在dcommit阶段没有隐藏某种通信问题。

更新：我还有一个想法：当我完成解决冲突时，我执行了git add foo.bar。git add .可能会做出意外的事情吗？我并没有真正地扩展git svn的能力，所以这些都是猜测。

- Hank Gay

可能是我在处理代码库时太过草率，但我不确定原因。我已经遇到了这种情况好几次，每次都不得不彻底清除并重新构建我的代码库。这让人非常沮丧。感谢您的建议。 - Rob Wilkerson

0

看起来有些东西不是你认为的那样运行。如果不是Hank Gay提出的不太可能的事情，那么就是其他不太可能的事情。

我的不太可能性是你的分支结构不是你想象的那样，或者你没有在你想象的分支上进行rebase。所以我建议你：

git branch 确认一下你的分支结构是否符合预期。
在~/.bash_profile中添加
export PS1='\e[0;31m\n\w$(__git_ps1 "(%s)") $ \e[m'
然后重新登录，
以显示分支（和任何正在进行的git命令）在你的提示符中：

/workspace/wikka(featurebranch1|REBASE-i) $

这将给你更多的反馈（并且可能消除这个WAG作为一个可能性）。

- Paul

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Justin · Accepted Answer

我建议使用git rebase而不是git merge。Svn保持线性历史，有时似乎会被git分支合并搞混。使用git rebase可以确保svn理解线性历史。

参见：http://learn.github.com/p/git-svn.html 以获取更多信息和指南。