我正在开发一个将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上的提交,而不仅仅是onmaster.所以我从我的分支机构提交SVN,然后依靠git svn rebaseonmaster来从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.
|   归档时间:  |  
           
  |  
        
|   查看次数:  |  
           16730 次  |  
        
|   最近记录:  |