回答:
主な欠点はディスク容量です。リポジトリ自体は、「チェックアウトされた」ファイルのセットと同じ容量になります。つまり、リポジトリのクローンを作成すると、コレクションのディスク容量は基本的に2倍になります。
さらに悪いことに、不要になったファイルを削除しても、リポジトリにコピーが残ってスペースを占有します。
複数のマシン間でファイルの双方向同期を行うように設計されているunisonのような同期ツールを確認することもできます。
これが悪い考えである理由を考えられますか？
Gitはそのような使用には適していません。
gitが機能する方法は、リポジトリデータを.git/フォルダーに保持することです。テキストの場合、これは問題ではなく、簡単に圧縮でき、ファイルは小さいです-リポジトリは1メガバイトか2メガバイトかもしれません。
圧縮データ（MP3、JPEGなど）をgitでさらに圧縮することはできません。データの2つのコピーを効果的に保存する必要があるため、必要なディスク領域が2倍になります（1つはファイル用、もう1つはリポジトリ用）。
テキストは小さく、圧縮可能であり、重要なことに、2つのリビジョンを簡単に「比較」できます-変更を保存するだけです。1行しか変更しない場合、gitはその1行（およびコミットメッセージなどの関連メタデータ）のみを保存します
バイナリファイルは差分をとるのが難しいため、100個のファイルのタグを変更すると（たとえば、アートワークを追加したり、ジャンルを変更したり）、gitはそれらのファイルの新しいコピーを.git/ディレクトリに保存します。音楽のメタデータからすべてのコメントを取り除いたとすると、gitはファイルの別の完全なコピーを保存します！これは、リポジトリが実際のファイルのサイズの2倍を超えることを意味します（10 GBの音楽があったとすると、音楽フォルダは30 GBを超えます）
私が言ったように、gitはそのようなものには適していません-それはソースコードを追跡することを目的としており、大きなバイナリファイルではなくテキストファイルに小さな変更をたくさん加えます。同期ツールが必要な場合は、音楽ライブラリの変更履歴を保持してもあまり意味がありません。
gitの使用を検討しているので、コマンドラインツールに満足していると思います。rsyncを使用してマシン間でiTunesライブラリを同期することを検討することをお勧めします。joshhuntが述べたように、最大の問題はiTunesがメディアファイルへの絶対パスを使用するため、iTunes Library.xmlファイルに次のようなものが含まれていることです。
<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>
すべてのマシンで同じOSと同じユーザー名を使用している場合、これは問題ではありません。ファイルを同じパスに置いておくと、問題なく動作します。そうでなければ、物事はもう少し複雑になります。
2つのスクリプトを記述できます。1つは、パスをmachineAからmachineBに、またはその逆に更新します。/User/Shared/Music/パスを同じにするためにiTunesライブラリをどこかに移動することができます（ただし、これはOS X-> Windowsでは機能しない場合があります）
など、マシン間でiTunesライブラリを同期するユーティリティがいくつかあります。
（この記事から）
バージョン管理システムは一般に、テキストファイルを処理するために設計されています。バイナリファイルを更新するたびに、単に差分を格納するのではなく、完全に新しいファイルを作成する必要があります。
これが実際の使用にどのように変換されるかは、ライブラリを定期的に変更すると、ライブラリが多くのディスク領域を使用することになるということです。
ライブラリファイル自体についてのみ話している場合は、これで問題ない可能性があります。
このセットアップのもう1つの問題は、iTunesがデータベースをプロプライエタリバイナリファイルとして保存することです。このファイルはgitがマージを実行できません（いいえ、iTunes Music Library.xmlファイルへの編集はiTunesによって読み込まれません）。 。したがって、メタデータに変更を加えた場合、または両方のマシンで追加のトラックを追加した場合、両端から行われた変更を調整する方法はなく、データベースの一方のバージョンを他方のバージョンで上書きし、その過程でデータを失うことになります。 。
上記のディスク容量の問題は確かに当てはまります。しかし、2つの別個の問題があります。1つは、リポジトリとデータを保存する必要があるため、各ファイルが2回保存されることです。2番目の問題は、メタデータを変更するたびに音楽のまったく新しいコピーが保存されるため、徐々にN回音楽を保存することになります。Nは継続的に増加します。最初の問題は大丈夫かもしれません、2番目は本当のドラッグです。
興味深いのは、Gitが2番目の問題に苦しんでいるのに対し、Subversionはそうではないということです。差分アルゴリズムはバイナリファイルで機能するため、変更内容のみを保存します。私が写真にSubversionを使用するのはそのためです。あなたの使用例と非常によく似ており、とても満足しています。
これは問題を説明するログです。Subversionは実際には3つのコピーを保存することに注意してください。1つはリポジトリに、1つは作業コピーの.svnディレクトリに、そして作業コピー自体です。ただし、メタデータを変更するため、余分なスペースは使用されません。
mat@Winter:~/temp$ git init repo
Initialized empty Git repository in /home/mat/temp/repo/.git/
mat@Winter:~/temp$ cp -r light_and_magic/ repo/
mat@Winter:~/temp$ cd repo/
mat@Winter:~/temp/repo$ du -hs .
101M .
mat@Winter:~/temp/repo$ git add light_and_magic/
mat@Winter:~/temp/repo$ git commit -m 'First commit'
...
mat@Winter:~/temp/repo$ du -hs .
191M .
mat@Winter:~/temp/repo$ id3v2 -a 'ladytron' light_and_magic/*.mp3
mat@Winter:~/temp/repo$ git commit -a -m 'changed metadata'
...
15 files changed, 0 insertions(+), 0 deletions(-)
mat@Winter:~/temp/repo$ du -hs .
282M .
mat@Winter:~/temp$ svnadmin create repo
mat@Winter:~/temp$ svn co file:///home/mat/temp/repo working
Checked out revision 0.
mat@Winter:~/temp$ cp -r light_and_magic/ working/
mat@Winter:~/temp$ svn add working/light_and_magic/
...
mat@Winter:~/temp$ svn commit -m 'First commit' working/
...
mat@Winter:~/temp$ du -hs repo
91M repo
mat@Winter:~/temp$ du -hs working/
201M working/
mat@Winter:~/temp$ id3v2 -a 'ladytron' working/light_and_magic/*.mp3
mat@Winter:~/temp$ svn commit -m 'changed metadata' working/
...
mat@Winter:~/temp$ du -hs repo/
91M repo/
mat@Winter:~/temp$ du -hs working/
201M working/