Question

上周，我在离开小镇前往当地分行做了一些改动。今天早上我想把所有这些变化都告诉公司的Svn存储库，但是我在一个文件中遇到了合并冲突：

提交期间合并冲突：您的文件或目录“build.properties.sample”可能已过时：版本资源与事务中的资源不对应。请求的版本资源已过期（需要更新），或者请求的版本资源比事务根更新（重新启动提交）。

我不确定为什么我得到了这个，但在尝试dcommit之前，我做了一个 git svn rebase 。那“覆盖”了我的承诺。为了从中恢复，我做了一个 git reset --hard HEAD @ {1} 。现在我的工作副本似乎是我期望的那样，但我不知道如何通过合并冲突;实际上我找不到任何可以解决的冲突。

任何想法都会受到赞赏。

编辑：只是想说明我在本地工作。我有一个引用svn / trunk（远程分支）的trunk的本地分支。我所有的工作都是在当地的干线上完成的：

$ git branch
  maint-1.0.x
  master
  * trunk
$ git branch -r
  svn/maintenance/my-project-1.0.0
  svn/trunk

同样， git log 目前在我的本地干线上显示了自上次提交Svn ID以来的10次提交。

希望能回答几个问题。

再次感谢。

Answer 1

你应该已经创建了一个本地分支，并完成了它的工作，然后当你回来时，你更新master，rebase到本地分支，合并回master然后dcommit。

所以我会尝试复制这些更改，以备份它们。

从has svn同步点创建本地分支，在那里合并您的更改。然后退出master分支中的更改，fetch，rebase到分支，从本地分支合并，修复任何冲突，然后dcommit。

$ git checkout -b backup    # create a local backup branch with all your work
$ git checkout master   
$ git checkout -b backup2   # 2nd copy just to be safe
$ git checkout master
$ git reset --hard <this is the revision of the last svn-id> # clean up master to make the svn merge easier
$ git svn fetch    # this should update to the current version on the svn server
$ git rebase master backup  # may get a conflict here, fix and commit
... # after conflict is fixed and commited
$ git checkout master 
$ git merge backup --ff  # merge in your local commits
$ git svn dcommit        # push back to the svn

您可以获得其他信息here

您可能感兴趣的另一个answer。

git-svn工作流程文章

Article

Answer 2

非常感谢VonC和sfassen对我的非凡耐心，解决方案有点自我解决。我不知道怎么或为什么，但也许我最初的rebase不起作用。为了解决这个问题，我最终再次进行了改变。从我当地的主干部门：

$ git co -b backup  # backup the commits to my local trunk
$ git co trunk      # return to the local trunk
$ git svn rebase    # rebase the trunk from the Svn server
$ git br -d backup  # delete the backup branch

当然，关键是这次改造工作。我不知道为什么当我第一次这样做时它不起作用，但我不能回滚时间，所以我不会纠缠它。

再次感谢大家对新手的建议和耐心。

Answer 3

要完成sfossen的excellent answer，请参阅以下详细信息：

使用git-svn，默认情况下会获得名为master的本地分支。你不应该对它做任何工作，只使用svn trunk分支与它保持同步：

git svn fetch 从本地中继分支上的svn trunk分支获取历史记录：它不会在您的工作目录中应用这些修改
git checkout master 打开行李分支（仅当您在另一个分行时）
git rebase trunk 将master与trunk同步。

但是，所有修改都应该在另一个本地分支上完成（我们称之为local-devel）。

git branch local-devel
的 git checkout local-devel

如果您有紧急解决方法：

git checkout master ：swith on master（），

git svn fetch ＆amp;＆amp; git rebase trunk 使用svn trunk
更新它
git branch fastfix && git checkout fastfix ，将其分支

修复错误，编译，测试，

git commit -a ：本地提交，

git svn dcommit 更新远程svn repo的修改

git checkout master && git rebase trunk ：再次更新主计划

git branch -D fastfix ：删除修补程序分支

git checkout local-devel && git rebase master ：返回dev，在您的开发分支上重播的主人更新历史记录

起初有点麻烦，但比以后应用的文件中的svn diff更舒服。

Answer 4

我有类似的情况。我在一个糟糕的网络连接上做git svn dcommit，但在某些时候失败了。我发现问题是由于Subversion存储库已经有了一个新的提交，但是本地的git-svn对应方认为提交还没有在SVN中。来自其他答案的解决方案没有帮助，但是这样做了：

git svn reset -r <last_svn_commit_git_was_aware_of>
git svn fetch
git svn rebase

在此之后我终于能够git svn dcommit没有任何错误。

Answer 5

我打算发表评论，但认为这值得更多关注......

git svn rebase 假设重写您的提交。从描述和评论中，我得到的印象是，在你重新定位之后，你强迫你的旧提交回到顶部。提交必须替换为不冲突的新版本。

为了避免不必浏览reflog，您可能希望在做git svn dcommit之前养成快速标记的习惯。 dcommit成功后，删除标记。如果代码失败，您可以执行git reset --hard后跟git merge <tag>。重新运行您的rebase以使您的历史记录恢复正常，重新标记并重新再次发送。

Answer 6

我读过几个地方，使用git svn使用单独的分支是不好的做法。有关git的东西提交没有像你期望的那样以svn出现。

http://progit.org/book/ch8-1.html的以下答案似乎是最干净的方式：

git svn rebase
git svn dcommit

我也尝试过上面最流行的选项，但它并不总是对我有用，因为git rebase不会回滚匹配svn上游但只回到最后一个git commit。

Git Svn dcommit错误 - 重启提交

6 个答案:

git-svn工作流程文章