ソース管理に.vcxproj.filterファイルを追加する必要がありますか？
Visual Studio 2010 Beta 2の評価中に、変換されたディレクトリでvcprojファイルがvcxprojファイルになったことがわかります。また、フォルダー構造の説明を含むように見える各プロジェクトと一緒にvcxproj.filterファイルがあります（\ Source Files、\ Header Filesなど）。
これらのフィルターファイルはユーザーごとに保存する必要があると思いますか、それとも開発グループ全体で共有してSCCにチェックインする必要がありますか？
私の現在の考えはそれらをチェックインすることですが、そうしない理由があるのか、それとも間違いなくチェックインするべき十分な理由があるのかと思います。
明らかな利点は、他の誰かのマシンを見ている場合にフォルダー構造が一致することですが、論理的に物事を再編成したいのでしょうか？
Visual Studioの以前のバージョン（少なくともバージョン6.0および2008）は、その情報を独自のプロジェクトファイル（それぞれ.dspおよび.vcprojファイル）に保存します。もちろん、SCCに追加するのが適切です。
この.filterファイルをSCCに含めない理由は考えられません
意図的に.filterをプルしました。 .vcxproj MSBuild形式に変換したときの.vcprojからのファイル情報。 1つの理由は、まさにあなたが指摘したことです。フィルターは純粋に論理的なビューであり、チームのメンバーごとに異なるビューが必要な場合があるためです。もう1つは、プロジェクトファイルのタイムスタンプをチェックし、変更された場合は再構築をトリガーするようにビルドが設定されることがあるということです。これは、ビルドするソースファイルや設定などが異なる可能性があるためです実際にビルドをそのようにトリガーして出荷した場合を思い出してください。ただし、ビルドに影響しないため、フィルターが変更されたという理由だけでリビルドをトリガーしたくないという考えでした。
Gitを使用すると、.filterファイルをマージして、より簡単にするための結合として扱うことができることがわかりました。行を追加するだけです：
*.vcxproj.filters merge=union
.gitattributesファイルに。
詳細については、 。gitattributesを使用してマージの競合を回避する を参照してください。
CMake（または同様のビルドツール）を使用して_*.sln_、_*.vcxproj_、_*.vcxproj.filters_などのファイルを生成する場合は、このファイルを追加しないでください。プロジェクトフォルダーおよびその他へのパスコンピューター固有のフォルダーのみ。