SVNまたはGitを使用する必要がありますか？[閉まっている]

新しい分散プロジェクトを始めています。SVNまたはGitを使用する必要がありますか。その理由は何ですか。

SVNは1つのリポジトリであり、多くのクライアントです。Gitは、それぞれがユーザーを持つ多数のクライアントリポジトリを持つリポジトリです。外部サーバーにプッシュすることなく、ローカルで自分の編集を追跡できるように分散化されています。

SVNはより中央に設計されており、Gitは各ユーザーが独自のGitリポジトリを持つことに基づいており、それらのリポジトリは変更を中央にプッシュします。そのため、Gitは個人のローカルバージョン管理を向上させます。

一方、TortoiseGit、GitExtensions（および「中央」のgitリポジトリをgithubでホストする場合は、独自のクライアント（GitHub for Windows）を選択できます。

SVNから抜け出すことを検討している場合は、Bazaarを少し評価することをお勧めします。これは、この分散要素を備えた次世代のバージョン管理システムの1つです。gitのように POSIXに依存しないため、ネイティブのWindowsビルドがあり、強力なオープンソースブランドがそれを支えています。

しかし、このような機能はまだ必要ないかもしれません。見てい分散VCSesの特徴、利点と欠点を。SVNのオファー以上のものが必要な場合は、1つ検討してください。そうでない場合は、SVNの（現在）優れたデスクトップ統合を使用することをお勧めします。

「Windowsでgitが良くない」というこの概念を理解したことがありません。私はWindowsでのみ開発を行っており、gitで問題が発生したことはありません。

私は間違いなくsubversionよりgitをお勧めします。これは、はるかに多用途であり、subversionが実際には不可能だった方法で「オフライン開発」を可能にします。考えられるほとんどすべてのプラットフォームで利用でき、おそらくこれまでに使用するよりも多くの機能を備えています。

これは、GitとSVN（2009年9月）について削除してから重複した質問で作成した回答のコピーです。

いい？通常のリンクWhyGitIsBetterThanXを除いて、それらは異なります。

1つはブランチとタグの安価なコピーに基づく中央VCSで、もう1つ（Git）はリビジョンのグラフに基づく分散VCSです。VCSのコアコンセプトも参照してください。

その最初の部分では、2つのプログラム（SVNとGit）の基本的な目的は同じであるが、実装方法がまったく異なるというふりをして、誤った情報が含まれたコメントが生成されました。SVNとGitの根本的な違い
を明確にするために、言い換えましょう：

• SVNは、第三の実装であるリビジョンコントロール：RCS、その後、CVS、最後にSVNはバージョン管理データのディレクトリを管理します。SVNはVCS機能（ラベル付けとマージ）を提供しますが、そのタグは単なるディレクトリコピー（ブランチのようなものですが、タグディレクトリ内の何かに「触れる」ことを想定していない）であり、そのマージはまだ複雑で、現在メタに基づいています-dataは、すでにマージされているものを記憶するために追加されました。

• 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つの主要な利点：

1. 大容量ファイルのサポート。コードに加えて、SVNを使用してホームディレクトリを管理しています。SVNは、TrueCryptファイルを妨害しない唯一のVCS（配布されているかどうかに関係なく）です（500MB以上のファイルを効果的に処理する別のVCSがある場合は修正してください）。これは、diff比較がストリーミングされるためです（これは非常に重要なポイントです）。Rsyncは双方向ではないため、受け入れられません。

2. 部分的なリポジトリ（サブディレクトリ）のチェックアウト/チェックイン。Mercurialとbzrはこれをサポートしておらず、gitのサポートは制限されています。これはチーム環境では良くありませんが、自分のホームディレクトリから別のコンピューターで何かをチェックアウトする場合に非常に役立ちます。

ただ私の経験。

さらに調査を行い、このリンクを確認した後：https : //git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

（以下の抜粋）：

• 信じられないほど高速です。私が使用した他のSCMはこれに対応できず、Subversion、Perforce、darcs、BitKeeper、ClearCase、CVSなど、多くのSCMを使用しています。
• 完全に配布されています。リポジトリの所有者は、私がどのように働くかを指示することはできません。ラップトップ上で切断されている間にブランチを作成して変更をコミットし、後で他の任意の数のリポジトリと同期することができます。
• 同期は多くのメディアで発生する可能性があります。SSHチャネル、WebDAV経由のHTTP経由、FTP、またはメッセージの受信者が適用するパッチを保持する電子メールを送信することによる。中央リポジトリは必要ありませんが、使用できます。
• ブランチはSubversionよりもさらに安価です。ブランチの作成は、41バイトのファイルをディスクに書き込むのと同じくらい簡単です。ブランチの削除は、そのファイルを削除するのと同じくらい簡単です。
• Subversionとは異なり、ブランチは完全な履歴を保持します。奇妙なコピーを実行してコピーをウォークスルーする必要はありません。Subversionを使用しているとき、ブランチが作成される前に発生したブランチ上のファイルの履歴を確認するのは面倒でした。#gitから：spearce：ページのSVNについて1つ理解できません。私はSVNにブランチを作成し、履歴を参照すると、ブランチ全体に履歴全体が表示されました
• Gitではブランチのマージがより簡単で自動化されています。Subversionでは、正しいマージコマンドを生成できるように、マージ元の最後のリビジョンを覚えておく必要があります。Gitはこれを自動的に行い、常に正しく実行します。つまり、2つのブランチをマージするときに間違いを犯す可能性が低くなります。
• ブランチのマージは、リポジトリの適切な履歴の一部として記録されます。2つのブランチをマージしたり、ブランチを元のトランクにマージしたりすると、そのマージ操作は、自分がいつ実行したかというように、リポジトリ履歴の一部として記録されます。ログのすぐそこにあるときに、誰がマージを実行したかを議論することは困難です。
• リポジトリの作成は簡単な操作です：mkdir foo; cd foo; git init以上です。つまり、私は最近すべてのGitリポジトリを作成しています。クラスごとに1つのリポジトリを使用する傾向があります。これらのリポジトリのほとんどは、講義ノート、宿題、および私のLaTeXの回答のみを保存するため、ディスク内で1 MB未満です。
• リポジトリの内部ファイル形式は非常にシンプルです。これは、修復が非常に簡単であることを意味しますが、修復が非常に簡単で、破損するのが非常に難しいため、さらに優れています。誰もGitリポジトリが破損したことはないと思います。fsfs自体が壊れているSubversionを見てきました。そして、私はBerkley DBが何度も自分自身を破壊して、私のコードをSubversionのbdbバックエンドに信頼できないのを見てきました。
• Gitのファイル形式は、非常に単純な形式ですが、データの圧縮に非常に適しています。MozillaプロジェクトのCVSリポジトリは約3 GBです。Subversionのfsfs形式で約12 GBです。Gitでは約300 MBです。

これらをすべて読んだ後、Gitが進むべき道だと確信しました（ただし、学習曲線は少しあります）。WindowsプラットフォームでもGitとSVNを使用しました。

上記を読んだ後、他の人の意見を聞きたいです。

Subversionリポジトリをセットアップします。このようにすることで、個々の開発者はSubversionクライアントとGitクライアントのどちらを使用するかを選択できます（git-svn）。を使用git-svnしても、完全なGitソリューションのすべての利点が得られるわけではありませんが、個々の開発者は独自のワークフローを大幅に制御できます。

私は、GitがUnixやMac OS Xで動作するのと同じようにWindowsでも動作するようになるまで、比較的短い時間だと思います（あなたが尋ねたため）。

Subversionには、エクスプローラー統合用のTortoiseSVNやVisual Studio統合用のAnkhSVNなど、Windows用の優れたツールがあります。

おもしろいのは、私はSubversion Reposでプロジェクトをホストしていますが、Git Cloneコマンドを介してプロジェクトにアクセスしています。

Google Code ProjectのDevelop with Gitをお読みください

Google CodeはSubversionをネイティブで話しますが、開発中にGitを簡単に使用できます。「git svn」を検索すると、この手法が広く普及していることが示唆されます。実験することをお勧めします。

SvnリポジトリでGitを使用すると、次のような利点があります。

1. 複数のマシンに分散して作業し、コミットしたりプルしたりできます
2. 他の人がチェックアウトできる中央の backup/public svnリポジトリがあります
3. そして、彼らは自分自身でGitを自由に使用できます

そうでもないあなたの質問に答えるが、あなたはのメリットたい場合は分散リビジョン管理を -あなたが行うように聞こえる-とWindowsを使っている私はあなたが使用したほうが良いと思うのMercurialをむしろそのMercurialははるかに優れたWindowsのサポートを持っているGitのよう。MercurialにもMacポートがあります。

チームがcvsやsvnなどのバージョンおよびソース管理ソフトウェアに既に慣れている場合、シンプルで小さなプロジェクト（そうだと主張するような）の場合は、SVNを使用することをお勧めします。私は本当にsvnに慣れていますが、私がdjangoで行っている現在のeコマースプロジェクトでは、gitに取り組むことを決めました（私はsvn-modeでgitを使用しています、つまり、プッシュとプルを行う集中化されたリポジトリを使用しています）少なくとも他の1人の開発者とコラボレーションするため）。他の開発者はSVNに慣れており、他の開発者の経験は異なる場合がありますが、私たち2人はこの小さなプロジェクトでgitを採用するのに本当に悪い時間を過ごしています。（それが重要である場合、私たちはどちらもハードコアLinuxユーザーです。）

もちろん、走行距離は異なります。

確かsvnに、Windowsは（せいぜい）世界の二流市民であるためgit（詳細については、http：//en.wikipedia.org/wiki/Git_（software）#Portabilityを参照）。

更新：リンク切れのため申し訳ありませんが、かっこを含むURIでSOを機能させることをあきらめました。[リンクが修正されました。-ed]

主なポイントは、Gitが分散型VCSであり、Subversionが集中型であるということです。分散型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の方が適していると思います。

Gitは、Windowsではネイティブにサポートされていません。Posixシステム用に最適化されています。ただし、CygwinまたはMinGWを実行すると、Gitを正常に実行できます。

最近はSVNよりもGitの方が好きですが、CVS、SVNの土地から来た場合は、しきい値を超えるまでに時間がかかります。

SVNよりもはるかに強力だと思うので、おそらくGitを選択します。安価なコードホスティングサービスが利用可能で、私にとって非常に効果的です。バックアップやメンテナンス作業を行う必要はありません-GitHubが最もわかりやすい候補です。

そうは言っても、Visual StudioとさまざまなSCMシステムの統合については何も知りません。SVNとの統合が著しく改善されると思います。

私は長い間SVNを使用してきましたが、Gitを使用するたびに、Gitは非常に強力で軽量であり、多少の学習曲線が必要ですがSVNよりも優れていると感じました。

私が指摘したのは、各SVNプロジェクトは、成長するにつれて、エクスポートしない限り非常に大きなプロジェクトになるということです。GITプロジェクトは（Gitデータとともに）サイズが非常に軽量です。

SVNでは、初心者から専門家までの開発者を扱ってきましたが、初心者や中間者が再利用するために別のSVNプロジェクトから1つのフォルダーをコピーすると、ファイルの競合が発生するようです。一方、Gitでは、フォルダーをコピーするだけで機能します。これは、Gitがすべてのサブフォルダーに.gitフォルダーを導入していないためです（SVNのように）。

長い間SVNでたくさんのことをやり遂げた後、共同作業やマージ作業が簡単なので、開発者と私をGitに移すことを最終的に考えています。また、1つの大きな利点は、ローカルコピーの変更をできるだけコミットできることです。 SVNとは異なり、サーバーのブランチに最後にプッシュされます（SVN（サーバーのリポジトリで変更を時々コミットする必要がある場合））。

私が本当にGitを使うべきかどうか決めるのを手伝ってくれる人はいますか？

それはこれに帰着します：

あなたの開発は直線的ですか？その場合は、Subversionを使用する必要があります。

一方、開発が直線的でない場合、つまり、さまざまな変更に対してブランチを作成し、そのような変更をメインの開発ライン（マスターブランチとして知られているGit）にマージして戻す必要があることを意味します。あなたのためにもっとたくさん。

Bzrを試しましたかか？

彼らは市場で他に何も好きではなかったので、それはかなり良いです、（Ubuntuを作る人々）はそれを作りました...

質問を拡張して、GitがMacOSでうまく機能するかどうか尋ねてもよいですか？

コメントに返信：ニュースをありがとう、私はそれを試してみるのを楽しみにしていた。自宅のMacにインストールします。

これに関する興味深い動画がYouTubeにあります。Linus Torwalds自身から：Goolge Tech Talk：Linus Torvalds on git

他の人々から指摘されているように、SVNはWindowsの下では良い選択のようです。

開発者の一部がGITを試してみたい場合、GITリポジトリでSVNリポジトリが再作成されるGIT-SVNを常に使用することがあります。その後、GITを使用してローカルで作業し、SVNを使用してその変更をメインリポジトリに公開できるはずです。

DVCSを使用する必要があります。これは、ソース管理における飛躍的な進歩のようなものです。個人的にはモノトーンを使っていますおり、その開発時間の短縮は終わりません。Windows、Linux、Macで使用しており、非常に安定しています。各プラットフォームでプロジェクトのナイトリービルドを実行するbuildbotさえあります。

配布中のDVCSは、通常、人々が変更をプッシュしたりそこからプッシュしたりするための中央サーバーを作成することを意味します。