私はSubversionを数年間使用しており、SourceSafeを使用した後は、Subversionが大好きです。TortoiseSVNと組み合わせると、それがどれほど優れているかは想像できません。
それでも、Subversionに問題があり、Gitなどの新しいバージョンの分散バージョン管理システムに移行する必要があると主張する開発者が増えています。
GitはSubversionをどのように改善しますか？
私はSubversionを数年間使用しており、SourceSafeを使用した後は、Subversionが大好きです。TortoiseSVNと組み合わせると、それがどれほど優れているかは想像できません。
それでも、Subversionに問題があり、Gitなどの新しいバージョンの分散バージョン管理システムに移行する必要があると主張する開発者が増えています。
GitはSubversionをどのように改善しますか？
回答:
GitはSubversionより優れていません。しかし、悪くはありません。違います。
主な違いは、分散化されていることです。あなたが出張中の開発者で、ラップトップで開発していて、3時間前に戻ることができるようにソース管理をしたいとします。
Subversionを使用すると、問題が発生します。SVNリポジトリが到達できない場所（会社内で、現在インターネットが利用できない）にある可能性があり、コミットできません。コードのコピーを作成する場合は、文字通りコピー/貼り付けする必要があります。
Gitでは、この問題は発生しません。ローカルコピーはリポジトリであり、それにコミットしてソース管理のすべての利点を得ることができます。メインリポジトリへの接続を回復したら、それに対してコミットできます。
これは一見良さそうですが、このアプローチに追加された複雑さを覚えておいてください。
Gitは「新しく、光沢があり、クールな」もののようです。それは決して悪いことではありませんが（結局のところ、LinusがLinuxカーネル開発のために書いた理由があります）、「分散ソース管理」トレインは、それが新しくてLinus Torvaldsによって作成されたからといって、実際にはないため、なぜ/それが良いかを知る。
Subversionには問題がありますが、Git、Mercurial、CVS、TFSなどでも問題があります。
編集：したがって、この回答は1年前のものであり、まだ多くの賛成票を生成しているので、もう少し説明を追加しようと思いました。これを書いてから昨年、特にGitHubのようなサイトが本当に普及して以来、Gitは多くの勢いとサポートを得てきました。最近はGitとSubversionの両方を使用していますが、個人的な洞察を共有したいと思います。
まず第一に、分散型で作業する場合、Gitは最初は本当に混乱する可能性があります。リモコンとは何ですか？および初期リポジトリを適切に設定するにはどうすればよいですか？特にSVNの単純な「svnadmin create」と比較すると、最初に出てくる2つの質問です。Gitの「git init」は、集中型を設定する「適切な」方法のように見えるパラメーター--bareと--sharedを取ることができます。リポジトリ。これには理由がありますが、複雑さが増します。「checkout」コマンドのドキュメントは、変更する人を非常に混乱させます-「適切な」方法は「git clone」のようであり、「git checkout」はブランチを切り替えるようです。
Git REALLYは、分散化されたときに本当に輝きます。私は自宅にサーバーを持ち、外出先にラップトップを持っています。SVNはここではうまく機能しません。SVNでは、リポジトリに接続していない場合、ローカルのソース管理ができません（はい、SVKまたはリポジトリをコピーする方法を知っています）。Gitでは、とにかくそれがデフォルトのモードです。ただし、これは追加のコマンドです（git commitはローカルでコミットしますが、git push origin masterはマスターブランチを "origin"という名前のリモートにプッシュします）。
上記のように：Gitは複雑さを追加します。リポジトリ作成の2つのモード、チェックアウトvsクローン、コミットvsプッシュ...ローカルで機能するコマンドと「サーバー」で機能するコマンドを知っている必要があります（私はほとんどの人がまだ中央の「マスターリポジトリ」を好むと想定しています） ）。
また、少なくともWindowsでは、ツールがまだ不十分です。はい、Visual Studioアドインはありますが、私はまだmsysgitでgit bashを使用しています。
SVNには、学習がはるかに簡単であるという利点があります。作成、コミット、チェックアウトの方法を知っていて、後で分岐、更新などをピックアップできる場合は、リポジトリとそれに向けたすべての変更があります。オン。
Gitには、一部の開発者が常にマスターリポジトリに接続されていない場合に適しているという利点があります。また、SVNよりもはるかに高速です。そして、私が聞いたところによると、サポートの分岐とマージははるかに優れています（これは、それが書かれた中心的な理由であるため、予想されます）。
これは、Gitがオープンソースプロジェクトに完全に適しているため、インターネットで話題になる理由も説明しています。Forkを実行し、変更を独自のForkにコミットして、元のプロジェクトメンテナーに変更をプルするよう依頼してください。Gitでは、これでうまくいきます。本当に、Githubで試してみてください。それは魔法です。
また、Git-SVNブリッジもあります。中央リポジトリはSubversionリポジトリですが、開発者はローカルでGitを操作し、ブリッジは変更をSVNにプッシュします。
しかし、このように長く追加されても、私は依然として私の中心的なメッセージを支持しています。「オフラインソース管理」が必要で、それを学ぶために余分な時間を費やす気がある場合、それは素晴らしいことです。しかし、厳密に一元化されたソース管理を行っている場合や、同僚が興味を持っていないためにそもそもソース管理の導入に苦労している場合は、SVNのシンプルさと優れたツール（少なくともWindowsの場合）が最適です。
Gitを使用すると、誰もが独自のリポジトリーを持っているため、実質的にオフラインで何でも実行できます。
ブランチを作成してブランチ間でマージするのはとても簡単です。
プロジェクトのコミット権限がない場合でも、独自のリポジトリをオンラインにして、パッチの「プッシュリクエスト」を公開できます。公式のメンテナーを含め、パッチが好きな人なら誰でも、それらをプロジェクトに取り込むことができます。
プロジェクトをフォークして修正し、HEADブランチからのバグ修正をマージし続けるのは簡単です。
GitはLinuxカーネル開発者向けに機能します。つまり、それは本当に高速である必要があり（そうでなければなりません）、数千の貢献者に拡張できます。Gitは、使用するスペースも少なくなります（Mozillaリポジトリーのスペースは最大30分の1になります）。
Gitは非常に柔軟で、非常にTIMTOWTDIです（それを行う方法は複数あります）。ワークフローは自由に使用でき、Gitがサポートします。
最後に、Gitリポジトリをホストするための優れたサイトであるGitHubがあります。
Gitの欠点：
他の答えは、Gitのコア機能（素晴らしい）をうまく説明しています。しかし、Gitの動作が改善され、私の人生をより健全に保つのに役立つ多くの小さな方法もあります。ささいなことのいくつかを次に示します。
git mvとgit rm。
「GitがXより優れている理由」では、Gitと他のSCMのさまざまな長所と短所の概要を説明しています。
簡単に：
いくつかの欠点があります：
最も単純な使用法では、SubversionとGitはほとんど同じです。以下の間に大きな違いはありません：
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
そして
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Gitが本当に優れているのは、分岐して他の人と協力することです。
まあ、それは配布されています。ベンチマークはそれがかなり高速であることを示し（その分散された性質を考えると、diffやログなどの操作はすべてローカルであるため、もちろんこの場合は非常に高速です）、作業フォルダーは小さくなります（それでも私の心を吹き飛ばします）。
Subversionやその他のクライアント/サーバーリビジョン管理システムで作業している場合、リビジョンをチェックアウトすることで、基本的にマシン上に作業コピーを作成します。これは、リポジトリがどのように見えるかのスナップショットを表します。更新によって作業コピーを更新し、コミットによってリポジトリを更新します。
分散バージョン管理を使用すると、スナップショットではなく、コードベース全体が得られます。3か月前のバージョンと比較したいですか？問題ありません。3か月前のバージョンがまだコンピュータに残っています。これは、処理がはるかに高速になるだけでなく、中央サーバーから切断されている場合でも、慣れている操作の多くを実行できることを意味します。言い換えれば、特定のリビジョンのスナップショットだけでなく、コードベース全体を持っているということです。
Gitはハードドライブ上で大量のスペースを占めると思いますが、私が見たいくつかのベンチマークから、実際にはそれほどかかりません。どのように私に尋ねないでください。つまり、それはLinusによって構築されたもので、彼は私が推測しているファイルシステムについて多少は知っています。
DVCSについて私が気に入っている主な点は、次のとおりです。
比較的大きなプロジェクトの主な理由は、ポイント3によって作成されたコミュニケーションの向上です。その他は素晴らしいボーナスです。
おもしろいのは、私はSubversion Reposでプロジェクトをホストしていますが、Git Cloneコマンドを介してプロジェクトにアクセスしています。
Google Code ProjectのDevelop with Gitをお読みください
Google CodeはSubversionをネイティブで話しますが、開発中にGitを簡単に使用できます。「git svn」を検索すると、この手法が広く普及していることが示唆されます。実験することをお勧めします。
SvnリポジトリでGitを使用すると、次のような利点があります。
backup/public svnリポジトリがありますここでのすべての答えは予想どおり、プログラマー中心ですが、会社がソースコードの外部でリビジョン管理を使用している場合はどうなりますか？バージョン管理の恩恵を受けるソースコードではないドキュメントがたくさんあり、他のCMSではなく、コードの近くに置く必要があります。ほとんどのプログラマーは孤立して作業するわけではありません-私たちはチームの一部として企業のために働いています。
これを念頭に置いて、Subversionとgitの使いやすさをクライアントツールとトレーニングの両方で比較してください。私はシナリオを見ることができない任意の分散型バージョン管理システムは、非プログラマに使用するか説明するのが容易になるだろうし。私はgitを評価することができ、実際にはプログラマーではないバージョン管理を必要とする人々に受け入れられることを期待しているので、私は間違っていることが証明されたいです。
それでも、なぜ集中型から分散型のリビジョン管理システムに移行する必要があるのかと経営陣から尋ねられたとしても、正直な回答をするのは難しいので、私たちには必要ありません。
免責事項：私はSubversionに早い時期（v0.29あたり）に興味を持ったので、明らかに偏見がありますが、それ以来私が働いてきた会社は、その使用を奨励し、サポートしてきたので、私の熱意から恩恵を受けています。これがほとんどのソフトウェア会社で起こっている方法だと思います。非常に多くのプログラマーがgitバンドワゴンに飛びついているので、ソースコードの外でバージョン管理を使用することの利点を逃してしまう企業はいくつあるのでしょうか。異なるチームに個別のシステムを使用している場合でも、メンテナンス、ハードウェア、トレーニングの要件を増やしながら、（統合された）問題追跡統合などのいくつかの利点を逃しています。
Subversionは、まだはるかに使用されているバージョン管理システムです。つまり、より優れたツールサポートを備えています。ほとんどすべてのIDE用の成熟したSVNプラグインが見つかり、（TurtoiseSVNなどの）優れたエクスプローラー拡張機能が利用可能です。それ以外は、Michaelに同意する必要があります。GitはSubversionよりも良くも悪くもありません。それは異なります。
David Richards WANdiscoのSubversion / GITに関するブログ
GITの出現により、GIT以外のものはくだらないと考えるDVCS原理主義者、つまり「ジッターン」の血統が生まれました。Gitteronsは、ソフトウェアエンジニアリングは自分たちの島で行われていると考えているようで、ほとんどの組織が上級ソフトウェアエンジニアだけを採用しているわけではないことを忘れがちです。それは大丈夫ですが、他の市場の考え方ではありません。私はそれを証明できてうれしいです：GIT、最後の見たところ、市場の3％未満でしたが、Subversionは500万人のユーザーと約半分のユーザーを抱えています。全体的な市場。
私たちが見た問題は、ジッターロンがSubversionで（安価な）ショットを発射していることでした。「Subversionはとても[遅い/安っぽい/制限的/においがしない/おかしな形で私を見る]のようなツイートで、GITを使用していて、[人生ですべてがうまくいく/妻が妊娠した/彼女ができた30年間の試行/私はブラックジャックテーブルで6回勝った] あなたは写真を取得します。
それは、何かを実行するために必要な使いやすさ/手順がすべてです。
PC /ラップトップで単一のプロジェクトを開発している場合は、セットアップと使用がはるかに簡単なので、gitの方が優れています。あなたはサーバーを必要とせず、マージを行うときにリポジトリのURLを入力し続ける必要もありません。
たった2人だったら、お互いにプッシュしたりプルしたりできるのでgitも簡単だと思います。
それを超えたら、私はsubversionに行きます。なぜなら、その時点で「専用の」サーバーまたは場所をセットアップする必要があるからです。
SVNと同様にgitでもこれを行うことができますが、中央サーバーと同期するために追加の手順を実行する必要があるため、gitの利点よりも重要です。SVNではコミットするだけです。gitでは、git commitを実行してから、git pushを実行する必要があります。余計なことをしてしまうだけで、追加の手順が煩わしくなります。
SVNにはより優れたGUIツールの利点もありますが、gitエコシステムはすぐに追いついているようで、長期的には心配する必要はありません。
一般にGitとDVCSは、誰もが独自のブランチを持っているため、互いに独立して多くのコーディングを行う開発者に最適です。ただし、他の誰かからの変更が必要な場合、彼女はローカルリポジトリにコミットする必要があり、その変更セットをあなたにプッシュするか、あなたが彼女からプルする必要があります。
私自身の推論では、集中化されたリリースなどを行う場合、DVCSによってQAおよびリリース管理が困難になると私は思います。誰かが他のすべてのリポジトリからそのプッシュ/プルを実行し、最初のコミット時に以前に解決されていた競合を解決してからビルドを実行し、他のすべての開発者にリポジトリを再同期させる責任があります。
もちろん、これはすべて人間のプロセスで対処できます。DVCSは、いくつかの新しい便利さを提供するために、一元化されたバージョン管理によって修正された何かを壊しました。
Gitが好きなのは、中規模から大規模のチームでコミュニケーション開発者から開発者に実際に役立つからです。分散バージョン管理システムとして、そのプッシュ/プルシステムを通じて、開発者が単一のプロジェクトで作業する開発者の大規模なプールを管理するのに役立つソースコードエコシステムを作成するのに役立ちます。
たとえば、5人の開発者を信頼し、そのリポジトリからのみコードをプルするとします。これらの開発者はそれぞれ、コードをプルするところから独自の信頼ネットワークを持っています。したがって、開発は、コードの責任が開発コミュニティ間で共有される開発者の信頼構造に基づいています。
もちろん、他の回答に記載されている他の利点もあります。
いくつかの回答がこれらを暗示していますが、私は2点を明確にしたいと思います：
1）選択的コミットを実行する機能（たとえばgit add --patch）。作業ディレクトリに同じ論理変更の一部ではない複数の変更が含まれている場合、Gitを使用すると、変更の一部のみを含むコミットを非常に簡単に作成できます。Subversionでは、それは困難です。
2）変更を公開せずにコミットする機能。Subversionでは、コミットはすぐに公開されるため、取り消しできません。これにより、「早期にコミットし、頻繁にコミットする」という開発者の能力が大幅に制限されます。
Gitは単なるVCSではありません。また、パッチを開発するためのツールでもあります。Subversionは単なるVCSです。
私はSubversionがうまくいくと思います...マージを開始するまで..または何か複雑なことをする..または何か何かを行うSubversionは複雑です（クエリを実行して、特定のファイルを破壊したブランチを見つけ、変更が実際にどこから来ているかを調べ、コピーと貼り付けを検出します）など）...
GIT の主な利点はオフラインでの作業であると言って、私は勝者の答えに同意しません。これは確かに便利ですが、私のユースケースでは追加のようなものです。SVKもオフラインで作業できますが、学習時間をどれに費やすかは私にとっては問題ありません）。
それはそれが信じられないほどパワフルで高速で、概念に慣れた後は非常に便利なだけです（そういう意味では、ユーザーフレンドリーです）。
マージの話の詳細については、これを参照してください： git-svn（または類似の）を使用して* s *だけでsvnマージを支援しますか？
セントラルリポジトリの水を汚すことなく、Gitでソースコードのローカルブランチを管理できることが大好きです。多くの場合、Subversionサーバーからコードをチェックアウトし、これを実行できるようにするためにローカルGitリポジトリを実行します。また、Gitリポジトリを初期化しても、ファイルシステムがどこにでもある煩わしい.svnフォルダーで汚染されないことも素晴らしいことです。
Windowsツールのサポートに関しては、TortoiseGitは基本を非常にうまく処理しますが、ログを表示したくない場合を除いて、コマンドラインを使用することをお勧めします。Tortoise {Git | SVN}がコミットログを読み取るときに役立つ方法が本当に気に入っています。
これは間違っている質問です。少なくとも一部のユースケースでは、gitのいぼに焦点を当てて、なぜSubversionが表面上優れているのかについての議論を立てるのは、あまりにも簡単です。gitはもともと低レベルのバージョン管理構築セットとして設計され、バロックなlinux開発者向けのインターフェースを備えているという事実により、聖戦が牽引力を発揮し、正当性を認めやすくなります。Gitの支持者は何百万ものワークフローの利点でドラムを叩きます。svnの連中は不必要だと宣言しています。すぐに、全体の議論は集中型と分散型の両方で構成され、エンタープライズsvnツールコミュニティの利益に役立ちます。これらの企業は通常、企業におけるsubversionの優位性について最も説得力のある記事を発表しています。
しかし、ここに問題があります。Subversionはアーキテクチャ上の行き止まりです。
一方、gitを使用して集中化されたsubversionの置き換えを非常に簡単に構築できますが、svnは基本的なマージ追跡をgitの場合と同様にどこでも機能させることができなかったため、2倍以上になります。これの基本的な理由の1つは、ブランチをディレクトリと同じにするという設計上の決定です。彼らが元々このように行った理由はわかりませんが、部分的なチェックアウトが非常に簡単になります。残念ながら、履歴を適切に追跡することも不可能です。明らかに、あなたはsubversionリポジトリのレイアウト規約を使用して通常のディレクトリからブランチを分離することになっています、そしてsvnはいくつかのヒューリスティックを使用して日常のユースケースで物事がうまくいくようにします。しかし、これらはすべて、非常に貧弱で低レベルの設計決定を制限することについて説明しているだけです。（ディレクトリごとの差分ではなく）リポジトリごとの差分を実行できることは、バージョン管理システムの基本的かつ重要な機能であり、内部を大幅に簡素化して、その上にさらにスマートで便利な機能を構築できるようにします。subversionの拡張に費やされた労力の量、およびマージの解決などの基本的な操作の面で、現在のVCSの現在の作物からどれだけ遅れているかがわかります。
さて、Subversionが近い将来に十分であるとまだ信じている人のための私の心からの不可知論的なアドバイスを次に示します。
Subversionは、RCSとCVSの間違いから学んだ新しい種類のVCSに追いつくことはありません。彼らがリポジトリモデルを根本から作り直さない限り、それは技術的に不可能ですが、それは実際にはsvnではないでしょうか？現代のVCSの機能をどれほど考えていなくても、無知はSubversionの落とし穴からユーザーを保護しません。その多くは、他のシステムでは不可能または簡単に解決できる状況です。
ソリューションの技術的な劣劣がsvnのように明確であることは非常にまれですが、win-vs-linuxまたはemacs-vs-viについてそのような意見を述べることは決してありませんが、この場合はそうです明確に、そしてソース管理は開発者の武器のような基本的なツールであり、私はそれが明確に述べられなければならないことを感じます。組織上の理由でsvnを使用する必要があるかどうかに関係なく、すべてのsvnユーザーには、より現代的なVCSは大規模なオープンソースプロジェクトにのみ有用であるという誤った考えを論理的な考えにさせないようにしてください。開発作業の性質に関係なく、プログラマーであれば、Git、Mercurial、Darcsなど、より適切に設計されたVCSの使用方法を学ぶと、より効果的なプログラマーになります。
Subversionは非常に使いやすいです。ここ数年、問題が発生したことや、期待どおりに動作しないことは一度もありません。また、多くの優れたGUIツールがあり、SVN統合のサポートが大きくなっています。
Gitを使用すると、より柔軟なVCSが得られます。すべての変更をコミットするリモートリポジトリでSVNと同じように使用できます。ただし、ほとんどの場合オフラインで使用して、変更を時々リモートリポジトリにプッシュすることもできます。しかし、Gitはより複雑で、学習曲線が急になります。私は初めて、間違ったブランチにコミットしたり、間接的にブランチを作成したり、間違いに関する情報が少ないエラーメッセージを受け取ったり、より良い情報を得るためにGoogleで検索する必要がある場所を見つけました。マーカーの置換などの簡単なもの（$ Id $）は機能しませんが、GITは非常に柔軟なフィルタリングと独自のスクリプトをマージするためのフックメカニズムを備えているため、必要なすべてのものを取得できますが、より多くの時間とドキュメントを読む必要があります;）
ローカルリポジトリでほとんどオフラインで作業している場合、ローカルマシンで何かが失われた場合、バックアップはありません。SVNを使用すると、ほとんどの場合、リモートリポジトリを操作します。これは、別のサーバーでのバックアップと同時に実行することもできます。Gitは同じように機能しますが、これはLinusがSVN2のようなものを持つことの主な目的ではありませんでした。Linuxカーネル開発者と分散バージョン管理システムのニーズのために設計されました。
GitはSVNより優れていますか？一部のバージョン履歴とバックアップメカニズムのみを必要とする開発者は、SVNを使用することで快適で快適な生活ができます。ブランチで頻繁に作業する開発者、同時により多くのバージョンをテストする開発者、またはほとんどオフラインで作業する開発者は、Gitの機能を利用できます。SVNにはないスタッシングのような便利な機能がいくつかあります。しかし一方で、すべての人がすべての機能を必要とするわけではありません。だから私はSVNの死者を見ることはできません。
Gitにはいくつかの優れたドキュメントが必要であり、エラー報告はより役立つはずです。また、既存の有用なGUIはほとんどありません。今回は、ほとんどのGit機能（git-cola）をサポートするLinux用のGUIを1つだけ見つけました。Eclipseの統合は機能していますが、公式にはリリースされておらず、公式の更新サイトはありません（トランクhttp://www.jgit.org/updatesから定期的にビルドされている一部の外部更新サイトのみ）したがって、Gitを使用する最も好ましい方法コマンドラインです。
SourceGearのEric Sinkは、分散バージョンコントロールシステムと非分散バージョンコントロールシステムの違いに関する一連の記事を執筆しました。彼は最も人気のあるバージョン管理システムの長所と短所を比較します。非常に興味深い読書。
記事は彼のブログwww.ericsink.comにあります。
優れたGit GUIを探している人にとって、Syntevo SmartGitは優れたソリューションとなるでしょう。そのプロプライエタリだが、非商用利用には無料で、Windows / Mac / Linuxで動作し、なんらかのgit-svnブリッジを使用してSVNもサポートしていると思います。
http://subversion.wandisco.com/component/content/article/1/40.html
開発者の間では、SVN Vと言ってもかなり安全だと思います。Gitの議論はここしばらくの間激怒しており、誰もがどちらが良いかについて自分自身の見解を持っています。これは、2010年およびそれ以降のSubversionに関するウェビナーでの質問でも取り上げられました。
オープンソースディレクターであり、Subversion Corporationの社長であるハイラムライトが、SubversionとGitの違い、および他の分散バージョン管理システム（DVCS）について語っています。
また、Working Copy Next Generation（WC-NG）など、Subversionで予定されている変更についても語っています。これにより、多くのGitユーザーがSubversionに再び変換されると考えています。
彼のビデオを見て、このブログにコメントするか、フォーラムに投稿して、ご意見をお寄せください。登録は簡単で、ほんの少しです！
WindowsのGitは、現在非常によくサポートされています。
GitExtensionsを確認してください= http://code.google.com/p/gitextensions/
Windows Gitエクスペリエンスを向上させるためのマニュアル。
私は最近Gitの土地に住んでいますが、個人的なプロジェクトにはそれが好きですが、スタッフからの要求に対する考え方が変わったため、差し迫ったメリットがなければ、まだSubversionから作業プロジェクトをそれに切り替えることはできません。さらに、社内で実行する最大のプロジェクトはsvn：externalsに大きく依存しています。これは、これまで見てきたことから、Gitでうまくシームレスに機能しないためです。
まず、並行バージョン管理は簡単に解決できる問題のようです。それはまったくありません。とにかく...
SVNは非常に直感的ではありません。Gitはさらに悪い。[皮肉な推測]これは、並行バージョン管理などの難しい問題のように、優れたUIを作成することにあまり関心がない開発者が原因である可能性があります。[/皮肉な憶測]
SVNサポーターは、分散バージョン管理システムは必要ないと考えています。私もそう思った。しかし、今ではGitのみを使用しているので、私は信者です。これで、バージョン管理は、プロジェクトで機能するだけでなく、私とチーム/プロジェクトで機能します。ブランチが必要なときはブランチします。サーバー上に対応するブランチがあるブランチである場合とない場合があります。私が勉強しなければならない他のすべての利点は言うまでもありません（一部は難解で、最新のバージョン管理システムであるUIの不合理な欠如に感謝します）。
なぜ私はSubversionがGitよりも優れていると思うのか（少なくとも、私が取り組んでいるプロジェクトでは）、主にその使いやすさ、およびワークフローの簡素化が原因です。
http://www.databasesandlife.com/why-subversion-is-better-than-git/