2～3人の小さなチームが2～3チームあります。私たちは皆、ローカルには git を使用し、中央リポジトリには svn を使用し、git-svn は同期されています。これは、チーム間でコードを共有したい場合を除いて、常に機能します。
そのため、git pull を試してみましたが、これにより多くの競合が発生し、同じツリー上にいることが検出されません。すべての変更をフェッチします（クローンしてからプルするのと同じです）もちろん、完全なリポジトリをクローンしたくありません。共有したいたびに。
より良い流れを提案してください。
1 人のチーム メンバーを「git ハブ」として指名します。そのメンバーは SVN サーバーと同期し、他のチーム メンバーは SVN サーバーと直接やり取りするのではなく、それらと対話します。そうすれば、git はすべてのチーム メンバーが同じツリー上にあることを認識します。
SubGitはあなたにとって素晴らしい代替手段のようです。
SubGitはサーバー側のソリューションであり、Subversion リポジトリへの Git アクセスを可能にし、その逆も可能です。つまり、選択した Git クライアントを使用して、Git リポジトリのみを操作できます。
SubGit を Subversion リポジトリに一度インストールする必要があります。その後、SubGit はすぐに svn リビジョンを git commit に変換し、git commit を everysvn commitで svn リビジョンに変換しますgit push。
SubGit はクローズド ソース ソフトウェアですが、オープンソース プロジェクトでは無料です。詳細については、SubGit ドキュメントを参照してください。
Chris Huang-Leaver の回答に追加するには、svn リポジトリで dcommit/rebase するための中心点が必要です。
これは、Git の「分散型」の側面を否定するものではありません。リモート リポジトリの 1 つとして、誰もが 1 つの参照用の「中央」リポジトリ (つまり、svn と同期するもの) を操作できるようにするだけです。
結果として得られるGit リポジトリはサブモジュールに分割できないため、(潜在的に巨大な) svn リポジトリからのすべてを複製する負担を回避する簡単な方法はありません。
これにより、少なくとも 1 つの「解決策」が残ります。これには、以下が含まれます。
明らかに自動化する必要がありますが、あるチームはそれらの git リポジトリの1 つを「中央」リポジトリとして集中し、SVN 同期の担当者はメインの (および非表示の) Git からのパッチでそれらの小さな Git リポジトリを更新します。 <=>SVN リポジトリ。