`git svn rebase` vs`git rebase trunk` [英] `git svn rebase` vs `git rebase trunk`

问题描述

我正在研究一个使用Subversion作为存储库的项目。因为我需要做一些无法发送到svn服务器的更改，所以我开始使用 git svn ，以便我可以执行本地签入。我的设置如下所示：

分支： trunk（跟踪svn trunk），master（非常接近svn中的内容）和topic。

  * ------------------中继线
 \ 
 * ----------- * ---------主人
 \ 
 * --------主题
  

工作流：

<$ p $ b $ git svn fetch
$ git svn rebase
$ git checkout -b topic
$ git rebase master $ b $ [on branch master] $ b [hack hack hack]
$ git commit -a
[一旦上游准备好了我的更改]
$ 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 和 git svn rebase ，
是 git svn rebase 在master上运行基本上与 git rebase trunk 在master上运行一样

是否有更合理的工作流程可供使用？好像有很多不断变化的分支和rebasing正在进行。我知道我希望能够在svn的任何东西上重新定义我的工作，但是好像我在进行更多的rebase而不是严格必要的。

解决方案

请注意，从 git svn ，as详见为什么是我们的和他们的与git-svn 相反的意思：

  git svn rebase 
  

这会从当前HEAD的SVN父级获取修订并重新绑定当前（未向SVN提交）对它起作用。

所以你不需要 git svn fetch c $ c> git checkout master 和 git svn rebase ，特别是如果您仅跟踪 trunk （ master 的父级）。

---

第二点， git svn dcommit 会为 master 上的每个新提交在SVN中创建修订，但您的工作流程不会显示任何新的在 master 上提交，仅在主题（它在 master ）

---

git svn dcommit 没有指定的分支会推送当前HEAD上的提交，而不仅仅是 master 。所以我从我的分支提交SVN，然后依靠 master 上的 git svn rebase 将提交返回SVN。我在 dcommited 后放弃了主题分支。这是不是犹太教？

他详细说明：

我无法将它们发送给SVN ...。上游想要冻结发行版的主干，同时，我正在为下一个版本开发功能。

但最终的问题是，是git rebase trunk master与master分支上的git svn rebase是一样的吗？如果是这样，那么我不需要经常更改我的分支，只是为了对抗SVN中的主分支。但如果不是这样，并且在我git svn rebase时发生了某种魔术，我想知道。

：
$ b $ a git svn fetch 后面跟着一个 git rebase trunk master 将相当于 git svn rebase 。

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 svn so that I could do local checkins. My setup looks like this:

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

*------------------ 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 fetch and git svn rebase, Is git svn rebase run on master basically the same as git rebase trunk run on master?

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.

解决方案

Note, from git svn, as detailed in "Why is the meaning of "ours" and "theirs" reversed with 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.

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

---

Second point, the git svn dcommit would 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)

---

The OP Sean McMillan comments:

According to the docs, git svn dcommit without 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 rebase on master to bring the commits back from SVN. I abandon the topic branch after I've dcommited. Is this not kosher?

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.

To which I reply:

A git svn fetch followed by a git rebase trunk master would be the equivalent of a git svn rebase.

这篇关于`git svn rebase` vs`git rebase trunk`的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！