8
我遇到了git-svn dcommits问题，使得git存储库无法跟踪哪些提交是哪个。Git-Svn dcommit导致分支分裂
我尝试确保git中的master分支总是跟随SVN存储库中的trunk。所以每当我工作时，我都在一个主题分支上。这里是我的情况：
在主题分公司工作了一段时间
git checkout -b my-topic
git commit -m "blah blah blah"
于是我决定，我想回合并我的分支掌握
git checkout master
git svn rebase #get any changes in svn
git rebase master my-topic
git merge my-topic --ff-only
直到这里，一切都进展顺利。我现在有主，我的话题加快速度，并在同一指向提交和整个历史是这样的：
A -- B -- C - master + my-topic
然而，当我做
git svn dcommit
我结束了看起来像这样一棵树（B和C提交我最初的话题制造）：
-- B -- C - my-topic
/
A -- B -- C - master + remotes/trunk
好像在dcommit过程中，混帐推提交多达SVN，然后把他们重回到顶部主。我认为这个问题是他们得到不同的提交者信息。我用乌龟plink和SSH密钥登录到svn。
犯git仓库尚未推到SVN有提交者信息如：
Collin Hockey <[email protected]>
承诺已经被推到了svn库有这个虽然：
chockey <[email protected]>
有任何方式我可以让这些分支分裂？我可以通过说
git rebase master my-topic
再次，但我觉得这应该是多余的。与此相关的主要问题是，一旦分支的更改被推送到SVN，git不再认为分支已被合并到任何地方。删除不再需要的旧分支会造成混淆。
这似乎工作更好一点，但提交仍然不同（他们也有不同的时间）。实际上有一种方法可以防止它们成为新的提交（或者只是自动更新两个分支上的提交），还是仅仅是使用git-svn桥接的中断？ – Collin 2011-04-08 16:00:02
@Collin这是git-svn的工作方式：SVN提供提交，而Git忠实地反映它们。没有办法改变这种行为（除了编写自己的Git-SVN同步工具，当然）。 – 2011-04-08 16:10:49
感谢您的信息。我会在dcommiting后坚持重新分配我的分支。作者文件的东西确实使我的历史更漂亮，虽然:) – Collin 2011-04-08 17:14:49