`git svn rebase` vs`git rebase trunk`

Question

我正在研究一個使用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 

。假定沒有一個承諾git svn fetch和git svn rebase之間SVN， 是git svn rebase上掌握基本相同git rebase trunk在主運行運行？

是否有更合理的工作流程使用？看起來好像有很多不斷變化的分支和重新發售。我明白，我希望能夠在svn的基礎上重新定義我的工作，但似乎我正在進行更多的rebase而不是絕對必要的。

Answer 1

注意，從git svn，如「Why is the meaning of 「ours」 and 「theirs」 reversed with git-svn」詳細介紹：

git svn rebase 

這當前磁頭的SVN父獲取修改和變基當前的（未提交到SVN）工作的反對。

所以你不需要git svn fetch之前你git checkout master和git svn rebase，特別是如果你只跟蹤trunk（的master父）。

---

第二點，git svn dcommit將會造成SVN修訂爲每個新提交的master，但您的工作流程上沒有顯示任何master新的提交，只有topic（未合併過上master）

---

的OP Sean McMillan評論：

根據該文檔，git svn dcommit沒有branc指定的h按下當前HEAD上的提交，而不僅僅是master。所以我承諾從我的分支SVN，然後依靠master上的git svn rebase將提交從SVN返回。我在dcommited之後放棄topic分支。這不是猶太教嗎？

他詳細介紹：

我不能送他們到SVN ...但。上游希望「凍結」發行版的主幹，同時，我正在爲下一個版本開發功能。

但最終的問題是，「是git的重訂主幹線同混帳SVN上的主分支底墊？」如果是的話，我並不需要不斷地改變我的分支，只是變基我的主分支反對SVN。但是，如果不是這樣，並且當我拼命改變基調時會發生某種魔術，我想知道。

要我答覆：

git svn fetch一個後跟一個git rebase trunk master將是git svn rebase的等價物。