8

我典型的 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位于较低的分支 ( story-xyz) 上，其中包含我的 git 提交消息、git 用户名和电子邮件以及 git 提交时间戳。上层分支的提交是新的 git 提交。他们使用我的 Subversion 用户名、我运行时的时间戳dcommit，并且提交消息具有git-svn-id附加到它们的字段。

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

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

4

1 回答 1

4

我不认为你真的错过了什么。不过，您可能正在做一些不必要的工作。在这种情况下，您有两个指向“更多工作”提交的指针，并且您要求 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

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

于 2009-06-01T19:12:25.687 回答