現在、私のプロジェクトv1（本番）はトランクにあり、v2（開発中）はSVNのブランチにあります。v2がv1にマージされる可能性はほとんどありません。
SVNではv1とv2の切り替えが非常に遅く、ブランチ駆動型の開発はSVNで苦痛であるため、近い将来Gitに移行したいと考えています。
私はローカルのGitリポジトリを使用git svnして今のところ使用することを考えており、後でチームの準備ができたらGitリポジトリを集中型サーバーにプッシュします。
dcommitSVNでv2およびv2ブランチを操作する場合、gitワークフローはどのようになりますか？今後、v1とv2を同時に管理するためのより良い方法はありますか？
ありがとう！
更新：私は次のことを考えています。これが良い考えかどうかコメントしてください：
どう思いますか？
最善の方法は、全員が遅かれ早かれgitに移動するようにすることです。それは単にこのようなことをよりよく処理します。Git svnは、ブランチをうまく処理するようには設計されていません。また、動作することもありますが、実際にはそれほど安全ではありません。私見ですが、私はgit開発者ではなく、試してみて苦痛を感じた経験から話しているだけです。私にとって、アップストリーム（あなた自身、あなたのチーム、または他の誰か）がgitに変換できれば、それは常にはるかに簡単です。突然問題はなくなります。
将来的には、Net-SNMPのgitおよびブランチ管理への変換で行ったことを実行できます。すべてをマージし、-soursを使用してv1プロジェクトをメインの開発ブランチに最初にマージします。これにより、基本的にバージョン履歴が新しいブランチ間の過去の開発の違いをすべて無視するように設定されますが、新しいパッチをv1に適用してツリーに追加し、それらの新しいパッチをv2にマージすることができます。このようにして、Net-SNMPには、多くの場合4〜5個のアクティブなブランチがあります。パッチは最も古い最も関連性の高いブランチに入り、上位にマージされます。突然、すべてのブランチにパッチを適用することを覚えているという問題がなくなりました。
単純なgitラッパースクリプトは複数ブランチのパッチ管理を自動化し、全体の努力はほとんど無害です。一部の主要なアーキテクチャの変更のみが軽微な頭痛の種となり、手動でのマージ/移植が必要になります。