为什么git-svn dcommit会在我的git repo中留下重复的提交？我可以阻止这样做吗？

Question

我典型的git-svn工作流程是:

git checkout -b story-xyz
git commit -a -m "work"
git commit -a -m "more work"
git checkout master
git svn fetch
git merge remotes/trunk
git checkout story-xyz
git rebase master (sometimes with -i)
git checkout master
git merge story-xyz

在这一点上,我让我的master和story-xyz分支指向同一个提交,提前一个或多个提交remotes/trunk.从那以后remotes/trunk,一切都在一个线性历史中.

last svn commit [remotes/trunk] <--- work <--- more work [master, story-xyz]

然后我跑了

git svn dcommit

我希望看到它们之间的提交remotes/trunk并master成为Subversion修订版,并最终得到一个单独的线性历史记录remotes/trunk,master并且story-xyz都指向最新版本,如下所示:

last svn commit <--- work <--- more work [master, story-xyz, remotes/trunk]

我的Subversion版本很好,但我最终得到了一个双分支结构.在我提交之前,分支的公共根是Subversion HEAD.两个分支都包含相同的提交系列,因为它们包含相同的差异.该分支story-xyz是一个分支的负责人,remotes/trunk并master在其他:

last svn commit <--- work <--- more work [master, remotes/trunk]
                  |
                  \- work <--- more work [story-xyz]

我在运行之前的git提交git svn dcommit是在下面的branch(story-xyz)上,我的git提交消息,git用户名和电子邮件,以及git commit timestamps.上部分支的提交是新的git提交.他们使用我的Subversion用户名,我运行时的时间戳dcommit,并且提交消息git-svn-id附加了字段.

这一切都好,我可以继续工作.问题是,我查看gitk看起来像一个未合并的分支story-xyz.很难说出我合并回来的故事分支和我没有合并的故事分支之间的区别master.发现它的最明显的方法是重复提交消息.我可以删除story-xyz分支,但感觉就像我没有正确使用git而且我已经失去了一些历史记录.

我错过了一些git-svn不会这样做的东西吗？或者这只是与Subversion交互的方式之一削弱了git的力量和自由？

Answer 1

我不认为你真的错过了什么。不过，您可能会做一些不必要的工作。在这种情况下，您有两个指向“更多工作”提交的指针，并且您要求 git-svn 移动其中之一。另一只还留在原处。

你真的不需要master分支。Git-svn 不关心你正在提交哪个分支。IIRC，它使用它可以在当前提交的祖先中找到的第一个 svn-remote。

我将提供另一个版本的工作流程：

git checkout -b story-xyz remotes/trunk
git commit -a -m "work"
git commit -a -m "more work"
git svn fetch
git rebase remotes/trunk (with -i, perhaps)
git svn dcommit

这应该会给你一棵没有多余分支的树。不过，您需要小心快进合并。