“`git rebase` vs ` `git rebase trunk`‘

Question

我正在进行一个使用subversion存储库的项目。因为我需要做一些还不能发送到svn服务器的更改，所以我开始使用git svn，以便能够进行本地签入。我的设置如下：

分支：主干(跟踪svn主干)、主控(非常接近svn中的内容)和主题。

*------------------ trunk
 \
  *-----------*--------- master
               \
                *-------- topic

工作流：

[on branch master]
$ git svn fetch
$ git svn rebase
$ git checkout -b topic
$ git rebase master
[hack hack hack]
$ git commit -a
[once upstream is ready for my changes]
$ git svn fetch
$ git checkout master
$ git svn rebase
$ git checkout topic
$ git rebase master
$ git svn dcommit
$ git checkout master
$ git svn rebase
$ git branch -d topic

假设没有人在git svn rebase和git svn rebase之间提交svn，那么是在主服务器上运行的 git svn fetch ，与在git svn fetch？上运行的 git rebase trunk 基本相同。

是否有更合理的工作流程可供使用？，似乎有很多变化的分支正在进行中。我知道我希望能够在svn中的任何内容之上重新定位我的工作，但似乎我做的重基工作比严格来说是必要的。

Answer 1

注:来自git svn，详见"为什么“我们的”和“他们的”的意思与git-svn相反？"：

git svn rebase

这将从当前头的SVN父节点获取修订，并将当前(未提交到SVN)的工作重新定位到它。

因此，您不需要在git svn fetch和git svn rebase之前使用trunk，尤其是当您只跟踪trunk(master的父级)时。

第二点，git svn dcommit将为master上的每一个新提交创建SVN中的修订版，但是您的工作流不会在master上显示任何新的提交，只显示在topic上(它从未在master上合并)。

欧肖恩McMillan的评论：

根据文档，没有指定分支的git svn dcommit将提交推到当前头上，而不仅仅是在master上。因此，我从我的分支中提交到SVN，然后依靠git svn rebase on master将提交从SVN中带回来。在我拥有了topic之后，我放弃了dcommited分支。这不是犹太的吗？

他详细说明：

我不能把他们送到SVN..。目前还没有。上游希望“冻结”主干以发布版本，同时，我正在为下一个版本开发功能。 但最终的问题是，“是git重基主干主机，就像git重基在主分支上一样？”如果是的话，那么我就不需要不断地更改我的分支了，只是为了将我的主分支重新定位到SVN上。但是如果不是的话，当我把svn重新定位的时候，会有某种魔法发生，我想知道。

对此，我的答复如下：

git svn fetch后面跟着git rebase trunk master将相当于git svn rebase。