我正在开发一个将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 rebase
onmaster
来从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 次 |
最近记录: |