`git svn rebase` vs`git rebase trunk`

Sea*_*lan 15 svn git rebase

我正在开发一个将subversion用于其存储库的项目.因为我需要进行一些无法发送到svn服务器的更改,我开始使用git svn以便我可以进行本地签入.我的设置如下:

分支: trunk(跟踪svn trunk),master(非常接近svn中的内容)和主题.

*------------------ trunk
 \
  *-----------*--------- master
               \
                *-------- topic
Run Code Online (Sandbox Code Playgroud)

工作流程:

[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
Run Code Online (Sandbox Code Playgroud)

假设没有人承诺在svn git svn fetch和之间运行git svn rebase, 是否git svn rebase在master上运行与在master上运行基本相同git rebase trunk

是否有更明智的工作流程?似乎有很多变化的分支和变基.我知道我希望能够在svn中的任何内容之上重新设计我的工作,但似乎我做的更多的是不是严格必要的.

Von*_*onC 17

请注意,来自git svn,详见" 为什么"我们的"和"他们的"的意思与git-svn相反 ":

git svn rebase
Run Code Online (Sandbox Code Playgroud)

这将从当前HEAD的SVN父级获取修订,并针对它重新定义当前(未提交到SVN)的工作.

所以,你不需要在git svn fetch你的面前git checkout master,并git svn rebase,特别是如果你只跟踪trunk(母公司master).


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


OP肖恩·麦克米兰的评论:

根据文档,git svn dcommit没有指定分支会推送当前HEAD上的提交,而不仅仅是on master.所以我从我的分支机构提交SVN,然后依靠git svn rebaseon master来从SVN返回提交.我以后放弃了topic分支机构dcommited.这不是犹太人吗?

他详细说明:

我还不能把它们发送到SVN ...... 上游希望"冻结"主干用于发布,同时,我正在为下一个版本开发功能.

但最终的问题是," git rebase trunk master和master分支上的git svn rebase一样吗? "如果是,那么我不需要经常更改我的分支,只是为了反对我的主分支对抗SVN.但是,如果不是,并且当我git svn rebase时会发生某种魔法,我想知道.

我回复:

A git svn fetch后跟a git rebase trunk master将相当于a git svn rebase.