15

私はリポジトリにSubversionを使用するプロジェクトに取り組んでいます。まだsvnサーバーに送信できない変更を加える必要があるため、git svnローカルチェックインを実行できるように使用を開始しました。私のセットアップは次のようになります。

ブランチ：トランク（svnトランクの追跡）、マスター（svnにあるものにかなり近い）、およびトピック。

*------------------ 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とgit svn rebase、 マスターで実行することは基本的にマスターで実行することと同じですか？git svn rebasegit rebase trunk

使用するより賢明なワークフローはありますか？ブランチの変更やリベースが行われているようです。svnにあるものの上に自分の作業をリベースできるようにしたいことは理解していますが、厳密に必要な数よりも多くのリベースを行っているようです。

4

1 に答える 1

19

git svnから、「なぜ「私たち」と「彼ら」の意味がgit-svnで逆になっているのか」で詳しく説明されていることに注意してください。

git svn rebase

これにより、現在のHEADのSVN親からリビジョンがフェッチされ、現在の（SVNにコミットされていない）作業がリベースされます。

したがって、特に（の親）のみを追跡する場合は、 andのgit svn fetch前は必要ありません。git checkout mastergit svn rebasetrunkmaster

2番目のポイントは、のgit svn dcommit新しいコミットごとにSVNにリビジョンを作成しmasterますが、ワークフローには、の新しいコミットは表示されmasterず、topic（にマージされることはありませんmaster）のみが表示されます。

OP Sean McMillanのコメント：

ドキュメントによるとgit svn dcommit、ブランチが指定されていない場合、コミットはだけでなく、現在のHEADにプッシュされmasterます。だから私は自分のブランチからSVNにコミットし、それからコミットをSVNから戻すためににgit svn rebase依存します。終わった後、私は枝masterを放棄します。これはコーシャではありませんか？topicdcommited

彼はそれを詳述します：

SVNに送信できません...まだ。アップストリームはリリースのためにトランクを「フリーズ」したいと考えていますが、その間、私は次のリリースの機能に取り組んでいます。

しかし、最終的な質問は、「gitrebaseトランクマスターはマスターブランチのgitsvn rebaseと同じですか？」です。そうであれば、SVNに対してマスターブランチをリベースするためだけに、ブランチを絶えず変更する必要はありません。しかし、そうではなく、svn rebaseをgitしたときに何らかの魔法が発生した場合は、知りたいと思います。

私が返信するもの：

aのgit svn fetch後にagit rebase trunk masterが続くのは、と同等ですgit svn rebase。

于 2012-05-18T12:07:57.177 に答える