`git svn rebase` 与 `git rebase trunk`

`git svn rebase` vs `git rebase trunk`

提问by Sean McMillan

I'm working on a project that uses subversion for their repository. Because I need to make some changes that can't be sent to the svn server yet, I started using git svnso that I could do local checkins. My setup looks like this:

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

Branches:trunk (tracking svn trunk), master (pretty close to what's in svn), and topic.

分支：trunk（跟踪 svn 主干）、master（非常接近 svn 中的内容）和主题。

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

Workflow:

工作流程：

[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

Presuming that no one commits to svn between git svn fetchand git svn rebase, Is git svn rebaserun on master basically the same as git rebase trunkrun on master?

假定没有人提交之间svn的git svn fetch和git svn rebase， 是git svn rebase上主基本相同的运行git rebase trunk在主机上运行？

Is there a more sensible workflow to use?It seems like there's a lot of changing branches and rebasing going on. I understand that I want to be able to rebase my work on top of whatever's in svn, but it seems like I'm doing more rebases than are strictly necessary.

有没有更合理的工作流程可以使用？似乎有很多不断变化的分支和变基正在进行。我知道我希望能够在 svn 中的任何内容之上重新设置我的工作，但似乎我正在做的重新设置比严格必要的要多。

回答by VonC

Note, from git svn, as detailed in "Why is the meaning of “ours” and “theirs” reversed with git-svn":

请注意，来自git svn，如“为什么“我们的”和“他们的”的含义与 git-svn 颠倒了“为什么”中所述：

git svn rebase

This fetches revisions from the SVN parent of the current HEAD and rebases the current (uncommitted to SVN) work against it.

这会从当前 HEAD 的 SVN 父级获取修订，并将当前（未提交给 SVN）的工作重新绑定到它。

So you don't need the git svn fetchbefore your git checkout masterand git svn rebase, especially if you track only trunk(parent of master).

所以你不需要git svn fetch在你的git checkout masterand之前git svn rebase，特别是如果你只跟踪trunk（ 的父级master）。

---

---

Second point, the git svn dcommitwould create revisions in SVN for each new commit on master, but your workflow doesn't show any new commit on master, only on topic(which isn't ever merged on master)

第二点，git svn dcommit将在 SVN 中为每个新提交创建修订master，但您的工作流程不会在 上显示任何新提交master，仅在topic（从未合并过master）

---

---

The OP Sean McMillancomments:

该OP肖恩·麦克米兰的评论：

According to the docs, git svn dcommitwithout a branch specified pushes the commits on the current HEAD, not just on master. So I commit to SVN from my branch, then rely on a git svn rebaseon masterto bring the commits back from SVN. I abandon the topicbranch after I've dcommited. Is this not kosher?

根据文档，git svn dcommit没有指定分支会推送当前 HEAD 上的提交，而不仅仅是master. 所以，我从我的分支承诺SVN，然后依靠git svn rebase上master带来的提交从SVN回来。我放弃了topic分支后dcommited。这不是犹太洁食吗？

He details that:

他详细说明：

I can't sent them to SVN... yet. Upstream wants to "freeze" the trunk for a release, meanwhile, I'm working on functionality for the next release.

But the ultimate question is, "is git rebase trunk master the same as git svn rebase on the master branch?" If it is, then I don't need to be constantly changing my branches, just to rebase my master branch against SVN. But if it's not, and there's some kind of magic happening when I git svn rebase, I want to know.

我还不能将它们发送到 SVN ...... 上游想要“冻结”一个版本的主干，同时，我正在研究下一个版本的功能。

但最终的问题是，“ git rebase trunk master 是否与 master 分支上的 git svn rebase 相同？”如果是，那么我不需要不断更改我的分支，只需将我的 master 分支重新设置为针对 SVN。但如果不是，并且当我 git svn rebase 时会发生某种魔法，我想知道。

To which I reply:

我回复：

A git svn fetchfollowed by a git rebase trunk masterwould be the equivalent of a git svn rebase.

Agit svn fetch后跟 agit rebase trunk master将等同于 a git svn rebase。