SVNは一つのリポジトリであり、たくさんのクライアントです。 Gitは多くのクライアントレポジトリを持つレポジトリで、それぞれにユーザーがいます。外部のサーバーに物事をプッシュしなくても、ローカルで自分の編集を追跡できるようになるまで分散されています。
SVNは、GitがそれぞれのGitリポジトリとそれらのリポジトリPushを持つ各ユーザに基づいている場合に、より中心的になるように設計されています。そのため、Gitはより良いローカルバージョン管理を個人に提供します。
当面の間、 TortoiseGit 、 GitExtensions のどちらかを選択できます（そして、あなたがgithub上であなたの "中央の" git-repositoryをホストするのであれば、それら自身--- クライアント - Windows用GitHub ）。
SVNから抜け出すことを検討しているのであれば、 Bazaar を少し評価することをお勧めします。これは、この分散要素を持つ次世代のバージョン管理システムの1つです。 gitのようにPOSIXに依存しないのでネイティブのWindowsビルドがあり、それを裏付ける強力なオープンソースブランドもあります。
しかし、あなたはまだこれらの種類の機能さえ必要としないかもしれません。ご覧ください 分散型VCSの機能、長所と短所 。 SVNが提供する以上のものが必要な場合は、それを検討してください。そうでなければ、SVNの（現在の）優れたデスクトップ統合を使い続けたいと思うかもしれません。
私は「gitがWindows上で良くない」というこの概念を理解したことがありません。私はWindowsの下で独占的に開発しています、そして私はgitに関して何の問題も経験したことがありません。
Subversionよりもgitを強くお勧めします。それは単に非常に汎用性が高く、Subversionが本当に不可能な方法で「オフライン開発」を可能にします。それは想像できるほとんどすべてのプラットフォームで利用可能で、おそらくあなたが今までに使ったよりも多くの機能を持っています。
ここに私が その後削除されたいくつかの重複した質問 Git対SVN（2009年9月）についての回答のコピーがあります。
いい？通常のリンク WhyGitIsBetterThanX とは別に、それらは異なります：
1つはブランチとタグの安価なコピーに基づく中央VCS、もう1つ（Git）はリビジョンのグラフに基づく分散VCSです。 VCSのコアコンセプト も参照してください。
その最初の部分は、2つのプログラム（SVNとGit）の基本的な目的は同じであるが、それらはまったく異なる方法で実装されているというふりをして、誤った情報を含むコメントを生成しました。
SVNとGitの基本的な違い を明確にするために、言い換えてみましょう。
SVNは revisioncontrol の3番目の実装です： RCS、CVS、最後にSVN manageバージョン管理されたデータのディレクトリ。 SVNはVCS機能（ラベル付けとマージ）を提供しますが、そのタグは単なるディレクトリコピー（ブランチのように、タグディレクトリ内の何かに「触れる」ことを想定していないことを除く）であり、そのマージはまだメタに基づいて複雑です-データは、すでにマージされたものを記憶するために追加されました。
Gitはファイルコンテンツ管理（ファイルをマージするためのツール）、真のバージョン管理システムに進化した、コミットのDAG（ Directed Acyclic Graph ）に基づき、ブランチはデータの履歴の一部であり（データ自体ではない）、タグは真のメタデータ。
同じことを達成し、同じ問題を解決できるので、「基本的に」違いがないと言うのは、非常に多くのレベルで偽りです。
- 複雑なマージが多数ある場合、SVNでそれらを実行すると、より長くエラーが発生しやすくなります。多数のブランチを作成する必要がある場合、特に多数のファイルが関係する場合は、SVNよりもGitを使用する方がはるかに簡単に、それらを管理してマージする必要があります（速度が重要になります）
- 進行中の作業の部分的なマージがある場合、Gitステージング領域（インデックス）を利用して必要なものだけをコミットし、残りを隠して、別のブランチに進みます。
- オフライン開発が必要な場合... Gitを使用すると、他のリポジトリで実行したいワークフローに関係なく、独自のローカルリポジトリで常に「オンライン」になります。
それでも、その古い（削除された）答えに対するコメントは主張しました：
VonC：実装の根本的な違い（違いは非常に根本的なものであり、私たちはこれに明確に同意しています）と目的の違いを混同しています。
これらは両方とも同じ目的で使用されるツールです。これが、以前にSVNを使用していた多くのチームがGitに有利にダンプすることに成功した理由です。
同じ問題を解決しなかった場合、この代替可能性は存在しません。
、私が答えた：
「代替性」...興味深い用語（ コンピュータープログラミングで使用 ）。
もちろん、GitはSVNのサブタイプではありません。
両方で同じ技術的機能（タグ、ブランチ、マージ）を実現できますが、Gitは邪魔にならず、ファイルのコンテンツに集中することができます、ツール自体については考えずに。
確かに（常に）SVNを単にGitで置き換えることはできません。「そのプログラムの望ましいプロパティ（正確性、実行されるタスクなど）を変更することなく」（前述の 代替可能性の定義 への参照です） ）：
- 1つは拡張リビジョンツールで、もう1つは真のバージョン管理システムです。
- 1つは、単純なマージワークフローと（あまり多くない）並列バージョンを備えた中小規模のモノリシックプロジェクトに適しています。その目的にはSVNで十分であり、Gitのすべての機能が必要なわけではありません。
- もう1つは、複数のコンポーネントに基づいた中規模から大規模のプロジェクト（ コンポーネントごとに1つのリポジトリ ）、複雑なマージワークフローの複数のブランチ間、ブランチ内の並列バージョン、レトロフィットマージ、等々。 SVNでもできますが、Gitの方がはるかに優れています。
SVNは、マージワークフローを使用して、あらゆるサイズのプロジェクトを管理することはできません。 Gitはできます。
繰り返しますが、それらの性質は根本的に異なります（異なる実装につながりますが、それはポイントではありません）。
1つはリビジョン管理をディレクトリとファイルとして表示し、もう1つはファイルのコンテンツのみを表示します（空のディレクトリがGitに登録さえしないように！）。
一般的な最終目標は同じかもしれませんが、それらを同じ方法で使用したり、同じクラスの問題（範囲または複雑さ）を解決したりすることはできません。
めったに引用されないSVNの2つの主な利点：
大規模ファイルのサポートコードに加えて、私は自分のホームディレクトリを管理するためにSVNを使用します。 SVNは私のTrueCryptファイルを詰まらせない唯一のVCS（分散型であろうとなかろうと）です（500MB以上のファイルを効果的に扱う他のVCSがあるなら私を修正してください）。これは、差分比較がストリーミングされるためです（これは非常に重要な点です）。双方向ではないので、Rsyncは受け入れられません。
部分リポジトリ（subdir）チェックアウト/チェックイン。 Mercurialとbzrはこれをサポートしておらず、gitのサポートは限られています。これはチーム環境では悪いことですが、自宅のディレクトリから別のコンピュータで何かを調べたい場合には非常に貴重です。
私の経験だけです。
より多くの調査をし、このリンクを検討した後： https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html
（以下の抜粋）：
- 信じられないほど速いです。私が使用した他のSCMはそれに追いつくことができませんでした、そして私はSubversion、Perforce、darcs、BitKeeper、ClearCaseおよびCVSを含む多くを使いました。
- それは完全に配布されています。リポジトリの所有者が私の仕事の仕方を決めることはできません。ラップトップから切断した状態でブランチを作成して変更をコミットし、後でそれを他のリポジトリと同期させることができます。
- 同期は多くのメディアで発生する可能性があります。 WebDAV経由のHTTP経由、FTP経由、またはメッセージの受信者によって適用されるパッチを含む電子メールの送信によるSSHチャネル。中央リポジトリは必要ありませんが、使用することができます。
- Subversionに比べて枝はもっと安いです。ブランチの作成は41バイトのファイルをディスクに書き込むのと同じくらい簡単です。ブランチを削除するのは、そのファイルを削除するのと同じくらい簡単です。
- Subversionのブランチとは異なり、彼らの完全な歴史を続けています。変なコピーを実行してコピーを調べる必要はありません。 Subversionを使っているとき、ブランチが作成される前に発生したブランチ上のファイルの履歴を見るのは厄介です。 from #git：spearce：私はこのページでSVNについて一つのことを理解していません。 SVNにブランチを作成し、履歴を閲覧すると、そのブランチ内のファイル全体の履歴が表示されます。
- Gitでは、ブランチのマージはより簡単でより自動化されています。 Subversionでは、マージした最後のリビジョンが何であるかを覚えておく必要があります。そうすれば、正しいマージコマンドを生成できます。 Gitはこれを自動的に行い、そして常に正しく行います。つまり、2つのブランチをマージするときにミスをする可能性が少なくなります。
- ブランチマージはリポジトリの適切な履歴の一部として記録されます。 2つのブランチをマージした場合、またはブランチを元のトランクにマージした場合、そのマージ操作はリポジトリ履歴の一部として、いつ実行されたかとして記録されます。ログのすぐ上にあるときに、誰がマージを実行したかを争うのは困難です。
- リポジトリの作成は簡単な操作です。mkdir foo; cd foo; git initこれで終わりです。これは私が最近すべてのもののためにGitリポジトリを作成することを意味します。私はクラスごとに一つのリポジトリを使う傾向があります。これらのリポジトリのほとんどは、講義ノート、宿題、そして私のLaTeXの回答しか格納していないので、ディスク内の1 MB以下です。
- リポジトリの内部ファイルフォーマットは非常に単純です。これは修復が非常に簡単であることを意味しますが、それがとても簡単であるためそれが破損するのは非常に難しいのでさらに良いです。誰かがGitリポジトリを破損させたことがあるとは思わない。私はSubversionがfsfsを使って自分自身を壊しているのを見ました。そして私は自分のコードをSubversionのbdbバックエンドに信頼させるには何度もBerkley DBが自分自身を破損するのを見ました。
- Gitのファイル形式は非常に単純な形式ですが、データの圧縮に非常に適しています。 MozillaプロジェクトのCVSリポジトリは約3 GBです。 Subversionのfsfsフォーマットでは約12 GBです。 Gitでは約300 MBです。
これらすべてを読んだ後、私はGitが進むべき道であると確信しています（ただし、少しだけ学習曲線があります）。 WindowsプラットフォームでもGitとSVNを使用しました。
私は上記を読んだ後に他の人が何を言わなければならないかを聞きたいですか？
Subversionリポジトリを設定します。こうすることで、個々の開発者はSubversionクライアントとGitクライアントのどちらを使用するか（git-svn付き）を選択できます。 git-svnを使用しても、完全なGitソリューションの利点が得られるわけではありません全個々の開発者が自分のワークフローを細かく制御できます。
UNIXやMac OS Xと同じようにGitがWindowsでも同じように動作するようになるまでには、もう少し時間がかかると思います（あなたが尋ねたので）。
Subversionには、エクスプローラー統合用のTortoiseSVNやVisual Studio統合用のAnkhSVNなど、Windows用の優れたツールがあります。
面白いことに、私はSubversion Reposでプロジェクトをホストしますが、Git Cloneコマンドでそれらにアクセスします。
お読みください Google CodeプロジェクトでGitを使って開発する
Google CodeはネイティブにSubversionを話しますが、開発中にGitを簡単に使用できます。 "git svn"を検索すると、このやり方が広まっていることを示唆しているので、ぜひ試してみることをお勧めします。
SvnリポジトリでGitを使うことは私に利益を与えます：
- 私はいくつかのマシン上で分散分散することができます。
- 私は他の人がチェックアウトできるように中央
backup/publicsvnリポジトリを持っています - そして彼らはGitを自分のために自由に使うことができます。
Windowsは、せいぜいsvnの世界で二流の市民であるため、間違いなくgit（ http://en.wikipedia.org/wiki/Git_（ソフトウェアを参照）詳細は#Portability を参照してください。
更新：リンク切れのため申し訳ありませんが、SOを括弧を含むURIで動作させることをやめました。 [リンクは修正されました。 -ed]
あなたのチームがすでにcvsやsvnのようなバージョンとソース管理ソフトウェアに精通しているなら、（あなたがそれを主張するような）単純で小さなプロジェクトのために、私はあなたがSVNに固執することを勧めます。私はsvnにとても慣れています、しかし私がDjangoでやっている現在のeコマースプロジェクトのために、私はgitに取り組むことに決めました（私はsvnモードでgitを使っています。少なくとも1人の他の開発者と協力するために）もう一人の開発者はSVNに慣れています、そして他の開発者の経験は異なるかもしれませんが、私たち二人はこの小さなプロジェクトのためにgitを受け入れるのに本当に悪い時を過ごしています。 （それが問題であれば、私たちはどちらも筋金入りのLinuxユーザーです。）
あなたの走行距離はもちろん変わるかもしれません。
実際には質問に答えていませんが、 Distributed Revision Control という利点が欲しいのであれば、それはあなたがしているように聞こえます - そしてあなたはWindowsを使っています Mercurial むしろGit as Mercurialの方がWindowsのサポートがはるかに優れています。 MercurialにはMacへの移植もあります。
重要な点は、Gitは分散型のVCSであり、Subversionは集中型のVCSです。分散VCSは理解するのがもう少し難しいですが、多くの利点があります。あなたがこの利点を必要としないならば、Subversionはより良い選択かもしれません。
もう一つの質問はツールサポートです。どのVCSがあなたが使用する予定のツールによってよりよくサポートされていますか？
編集：3年前私はこのように答えました：
そしてGitは現時点ではCygwinまたは MSYS を介してのみWindows上で動作します。 Subversionは最初からWindowsをサポートしていました。 Gitのほとんどの開発者はLinuxで作業をしていて最初から携帯性を持っていなかったので、Windows用のgitソリューションがあなたのために働くかもしれないので、問題があるかもしれません。現時点では、Windowsでの開発にはSubversionを好むでしょう。数年間でこれは無関係かもしれません。
今世界は少し変わった。 Gitは現在、Windows上で優れた実装をしています。私は（もはやこのシステムを使用していないので）徹底的にWindows上でテストしなかったが、私はすべての主要なVCS（SVN、Git、Mercurial、Bazaar）が現在適切なWindows実装を持っていると確信している。 SVNに対するこの利点はなくなりました。他の点（集中型と分散型、およびツールサポートの確認）は有効です。
SVNは広く普及していることがよく知られているので、私はSVNを選択します。
LinuxユーザーにとってはGitの方が良いと思います。
それはこれに来ます：
あなたの開発は直線的でしょうか？もしそうなら、Subversionに固執する必要があります。
一方で、あなたの開発が線形ではないなら、それはあなたが異なる変更のためにブランチを作成し、そしてそのような変更をメイン開発ライン（Gitにマスターブランチとして知られる）に戻す必要があることを意味あなたのためにもっとたくさん。
私はSVNを長い間使ってきましたが、Gitを使うときはいつでも、Gitは非常に強力で軽量であり、学習曲線は少し含まれていますがSVNよりも優れていると感じました。
私が注目したのは、各SVNプロジェクトは、成長するにつれて、エクスポートされない限り非常に大きなサイズのプロジェクトになるということです。 GITプロジェクトは（Gitデータと共に）非常に軽量です。
SVNでは、私は初心者から専門家まで開発者と取引をしました、そして、初心者と中間者はそれを再利用するために別のSVNプロジェクトから1つのフォルダーをコピーするならファイル衝突を導入するようです。 Gitでは、そのフォルダをコピーするだけでうまくいくと思います。なぜなら、Gitはそのすべてのサブフォルダに.gitフォルダを導入していないからです（SVNのように）。
SVNと長い間取引してきましたが、コラボレーションや作業のマージが簡単で、ローカルコピーの変更も同じくらいコミットできるという点で、開発者と私をGitに移行するつもりです。 SVNとは異なり、サーバー上のリポジトリで変更をコミットする必要がある場合は異なります。
私が本当にGitを使うべきかどうかを決めるのを手伝ってくれる人はいますか？
GitはWindowsではネイティブにはサポートされていません。それはPosixシステム用に最適化されています。しかし、CygwinまたはMinGWを実行すると、Gitを正常に実行できます。
今日ではSVNよりもGitを好みますが、CVS、SVNの土地から来た場合、しきい値を超えるにはしばらく時間がかかります。
SVNよりはるかに強力だと思うので、おそらくGitを選択します。安いコードホスティングサービスが利用できます - バックアップやメンテナンス作業は必要ありません - GitHub が最も明らかな候補です。
とは言っても、私はVisual StudioとさまざまなSCMシステムの統合に関して何も知りません。私はSVNとの統合が特に優れていると思います。
これについてはYouTubeで興味深いビデオがあります。 Linus Torvalds自身によるものです。 Google Tech Talk：Linus Torvalds氏のgit
質問を拡大して、GitがMacOSでうまく動作するかどうかを尋ねてもいいですか。
コメントに返信：ニュースをありがとう、私はそれを試してみるのを楽しみにしていました。私は私のMacの自宅でそれをインストールします。
Bzr を試しましたか？
それはかなり良い、connonical（Ubuntuを作っている人たち）は、彼らが市場で他に何も好きではなかったのでそれを作りました...
他の人が指摘したように、SVNはWindowsの下では良い選択のようです。
あなたの開発者の何人かがGITを試したいのであれば、SVNリポジトリがGITリポジトリに再作成されるGIT-SVNを常に使うかもしれません。そうすれば、彼はGITを使ってローカルで作業して、SVNを使ってその変更をメインリポジトリに公開できるはずです。
あなたはDVCSを使わなければなりません、それはソース管理における飛躍的な進歩のようなものです。個人的には Monotone を使用していますが、開発期間が短縮されています。私たちはWindows、LinuxそしてMacにそれを使っています、そしてそれは非常に安定しています。私はbuildbotに各プラットフォームで毎晩プロジェクトのビルドをさせることさえあります。
DVCSは通常、配布されている間、人々が変更をやり取りするための中央サーバーを作成することを意味します。