我正在开发一个使用 subversion 作为存储库的项目。因为我需要进行一些还无法发送到 svn 服务器的更改，所以我开始使用git svn这样我就可以进行本地签到。我的设置如下所示：
分支机构：trunk（跟踪 svn trunk）、master（非常接近 svn 中的内容）和 topic。
*------------------ 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
假设没有人在 svn 之间提交git svn fetch and git svn rebase,
Is git svn rebase在master上运行基本相同git rebase trunk跑在主人身上？
是否有更合理的工作流程可供使用？似乎有很多分支的变化和基础的改变正在进行。我知道我希望能够在 svn 中的任何内容之上重新调整我的工作，但似乎我所做的重新调整比严格必要的要多。
注意，从git svn http://schacon.github.com/git/git-svn.html，详见“为什么 git-svn 中“我们的”和“他们的”的含义颠倒了 https://stackoverflow.com/questions/2959443/why-is-the-meaning-of-ours-and-theirs-reversed-with-git-svn/2960751#2960751":
git svn rebase
这会从当前 HEAD 的 SVN 父级获取修订版本，并根据它重新调整当前（未提交到 SVN）工作。
所以你不需要git svn fetch在你之前git checkout master and git svn rebase，特别是如果您只跟踪trunk（父母master).
第二点，git svn dcommit将为每个新提交在 SVN 中创建修订master，但是您的工作流程没有显示任何新的提交master，仅在topic（从未合并过master)
The 肖恩·麦克米兰 https://stackoverflow.com/users/117587/sean-mcmillan评论：
根据文档，git svn dcommit没有指定分支会将提交推送到当前 HEAD，而不仅仅是master。所以我从我的分支承诺 SVN，然后依赖git svn rebase on master从 SVN 取回提交。我放弃了topic我之后的分支dcommited。这不是犹太洁食吗？
他详细说明：
我还不能将它们发送到 SVN...上游想要“冻结”主干以进行发布，同时，我正在研究下一个版本的功能。
但最终的问题是，“git rebase trunk master 与 master 分支上的 git svn rebase 相同吗？“如果是，那么我不需要不断地改变我的分支，只是为了针对 SVN 重新调整我的 master 分支。但如果不是，并且当我 git svn rebase 时会发生某种魔法，我想知道。
对此我回复：
A git svn fetch随后是一个git rebase trunk master相当于git svn rebase.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
