5

SVN リポジトリに保存されているオープンソース プロジェクトを変更しています。変更が完了するまでにはしばらく時間がかかる可能性が高いため、git-svn ブリッジを使用してプロジェクトを Git リポジトリとしてチェックアウトしました。プロジェクトの Subversion リポジトリにアクセスできないため、変更を反映することはできませんが、Git リポジトリを (GitHub で) 公開して、他の人が変更の開発を追跡できるようにしたいと考えています。

「git svn」リポジトリを更新するgit svn rebaseには、名前が示すように、Subversion リポジトリからの新しい変更の上にすべての変更をリベースするを使用します。もちろん、リベースしたブランチをパブリック Git リポジトリにプッシュするのは良い考えではないため、SVN リポジトリから複製されたリポジトリに関して、関連する質問がいくつかあります。

  1. リベースされたブランチ (を使用git-svn rebase) をパブリック リポジトリに公開するのは安全ですか?
  2. Git のマスター ブランチが SVN リポジトリからの変更をリベースするブランチであると仮定すると、そのリポジトリで実際の開発を行うべきではないことを理解しています。つまり、変更を master にマージする場合は、それらを SVN リポジトリにプッシュする必要があります ( を使用git svn dcommit)。このポリシーを順守する場合、リベースされたマスター ブランチをパブリック リポジトリに公開しても問題ありませんか?
4

1 に答える 1

1

  1. SVN ブランチを公開しても安全ですが、git-svn dcommit. ブランチに変更がない場合git-svn rebaseは、早送りします。

    公開されたブランチから誰かがブランチする場合、それが SVN リポジトリからのものであることを知っていることが重要です。これは、彼らの変更を受け入れようとした場合、それらを SVN リポジトリにプッシュする唯一の方法は、本質的に変更をリベースすることであるからです。コミットされた変更を再度公開した後、ハッシュが一致しないため、競合するコミットに対処する必要があります。

  2. で作業するのは安全ですmasterが、おそらく実用的ではありません。上記から、実行するまでコミットを公開できませんgit-svn dcommit。したがって、コミットしたくない作業がある場合は、最新の SVN コミットを公開する前に、それを別のブランチに移動する必要があります (つまりgit-svn rebase; git push) 。

于 2009-09-29T21:11:50.170 に答える