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和{{1}的线性历史记录所有人都指向最新版本，如下所示：

story-xyz

我的Subversion版本很好，但我最终得到了一个双分支结构。在我提交之前，分支的公共根是Subversion HEAD。两个分支都包含相同的提交系列，因为它们包含相同的差异。分支last svn commit <--- work <--- more work [master, story-xyz, remotes/trunk]位于一个分支的头部，story-xyz和另一个分支remotes/trunk：

master

我在运行last svn commit <--- work <--- more work [master, remotes/trunk] | \- work <--- more work [story-xyz]之前的git提交位于较低的分支（git svn dcommit）上，包含我的git提交消息，git用户名和电子邮件以及git commit timestamps。上部分支的提交是新的git提交。他们使用我的Subversion用户名，即运行story-xyz时的时间戳，并且提交消息附加了dcommit字段。

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

我是否遗漏了阻止story-xyz这样做的事情？或者这只是与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

这应该会给你一棵没有额外分支的树。但是，您需要注意快进合并。

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

1 个答案: