git-svn：重置 master 的跟踪

Question

我正在使用 git-svn 来处理 SVN 存储库。我的工作副本是使用 git svn clone -s http://foo.bar/myproject 创建的，以便我的工作副本遵循 SVN 的默认目录方案（主干、标签、分支）。

最近，我一直在研究一个使用 git-svnbranch myremotebranch 创建并使用 git checkout --track -b mybranch myremotebranch 签出的分支。我需要在多个位置工作，因此我经常从分支将 git-svn dcommit 文件发送到 SVN 存储库。

完成更改后，我切换回主服务器并执行合并，提交合并，并尝试将成功的合并提交到远程主干。

似乎合并后，主服务器的远程跟踪已切换到我正在处理的分支：

# git checkout master
# git merge mybranch
... (successful)
# git add .
# git commit -m '...'
# git svn dcommit
Committing to http://foo.bar/myproject/branches/myremotebranch ...
#

有没有办法可以更新主服务器，使其遵循remotes/trunk合并之前？

我正在使用 git 1.7.0.5，如果有帮助的话。

如果您还可以解释为什么会发生这种情况，那将会很有用，这样我就可以避免问题再次发生。谢谢！

编辑：

这是我当前的.git/config：

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    autocrlf = false
[svn-remote "svn"]
    url = http://foo.bar/myproject
    fetch = trunk:refs/remotes/trunk
    branches = branches/*:refs/remotes/*
    tags = tags/*:refs/remotes/tags/*
[branch "mybranch"]
    remote = .
    merge = refs/remotes/myremotebranch

所以看来主干指向正确的位置。然而，切换到分支然后返回主分支并没有帮助； master 中的 git svn dcommit 仍尝试推送到 myremotebranch。

Answer 1

当主干上没有更改时，git 会进行快进合并，并将本地“主”分支设置为您分支上的提交。 Git-svn 不知道如何将快进合并提交回主干，事实上它认为“master”现在指向 svn 分支。

要解决此问题，请在合并时使用 git merge --no-ff 。这将强制 git 创建一个合并提交，然后可以将其提交到 svn。

Answer 2

如果您在切换回 master 后进行 git svn rebase 并使用 --squash ，则可以避免这种情况。

# git checkout master
# git svn rebase   //(<--the missing step)
# git merge --squash mybranch // (<-- doesn't commit, more like an svn merge would do)
... (successful)
# git add . 
# git commit -m '...' 
# git svn dcommit
Committing to http://foo.bar/myproject/trunk...
#

要解决当前状态（即您的 master 指向 SVN 分支），

您可以“切换”到另一个分支，删除 master，“切换”回它，然后再次合并：

# git checkout mybranch
# git branch -D master
# git checkout -b master trunk
... continue with merge...
# git merge --squash mybranch

...您现在已将 mybranch 合并到 master 中，并且准备好commit，然后dcommit到trunk

Answer 3

如果您尚未在 master 上进行任何提交，则意味着 git merge mybranch 是快进式的：master HEAD 只需移至 mybranch HEAD代码>.

这可以解释为什么 git svn dcommit 将您的更改推送到 SVN mybranch。
它会：

• 首先使用尚未提交的最后一个 Git mybranch 提交更新相应的 SVN 分支，
• 将合并记录到 SVN 端的 trunk
• ，然后它将在 Git 端对 master 进行 rebase（无需执行任何操作，已经在那里了）。

我不认为 master 没有改变它的引用，但如果你有疑问（并且你的工作目录是干净的），你可以（如果 master 当前已签出）：

git reset --hard remotes/trunk

Answer 4

一般来说，您不应该将 git merge 与 git svn 一起使用，因为 svn 即使有分支也不支持 git 那样的合并跟踪。当您需要合并分支时，我最成功的方法是（至少在最近的 svn 中）执行简单的 svn 签出/合并过程，然后使用 git svn rebase 更新我的 git-svn 存储库。这保留了 svn 的本机合并跟踪元数据，而 (AFAIK) git-svn 完全不知道这一点。

我不完全确定你的 svn 存储库处于什么状态——我会检查以确保合并 dcommit 在主干上执行了你想要的操作。即使这样做了，
我敢打赌，如果您查看存储库中的 refs/heads/master 和 refs/remotes/trunk 文件的内容，您会发现它们在以下位置有所不同：那一刻。如果是这种情况，我会（不存在本地更改）执行 git-svn fetch ，然后执行 gitbranch -f masterremotes/trunk; git reset --hard master 将 git 分支与 git-svn 跟踪分支重新同步。如果您有本地更改，则必须提交并执行类似 git rebase master^4 --onto remotes/trunk 的操作，其中 4 是您需要保留的提交数量。或者，如果它们都未提交，请先使用 git stash 隐藏它们。

如果做不到这一点，你总是可以将所有内容放入 svn 中，然后擦除存储库并重新签出。

Answer 5

我们已经在 git-svn 功能分支开发中成功使用了 git merge --squash 。 git-svn 的问题是，虽然本地 git-svn 克隆可以存储合并信息，但一旦您提交到 svn 存储库，它就会丢失。

因此，对于其他 (git-)svn 用户来说，合并提交看起来就像普通提交一样。挤压与 git merge --no-ff 具有相同的作用（例如，在 master 上生成合并提交），但它还包含在正在合并的分支中进行的实际提交的列表，否则在 dcommitting 时会丢失。

Answer 6

我遇到了同样的问题，我将遥控器/主干合并回主干，之后 git svn info 指向主干，

当我离开项目时，我没有时间实际进行 dcommit，并且我的 git-svn 存储库因我的糟糕而死亡。我确实尝试了 dcommit --dry-run ，它说它将提交回主干。

时，我会重现设置和测试

当我有时间欢呼