git - SVN または Git を使用する必要がありますか?

Question

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

score 255 · Accepted Answer

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

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

一方、TortoiseGit、GitExtensionsのいずれかを選択できます (また、「中央」の git リポジトリを github でホストしている場合は、独自のクライアント – GitHub for Windows )。

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

しかし、この種の機能はまだ必要ないかもしれません。分散型 VCS の機能、長所と短所をご覧ください。複数の SVN オファーが必要な場合は、1 つを検討してください。そうでない場合は、SVN の (現在の) 優れたデスクトップ統合に固執することをお勧めします。

score 112 · Accepted Answer

「gitはWindowsではうまくいかない」というこの概念を理解したことがありません。私はもっぱら Windows で開発を行っていますが、git で問題が発生したことは一度もありません。

Subversion よりも git をお勧めします。それは単純に非常に汎用性が高く、Subversion が実際にはできなかった方法で「オフライン開発」を可能にします。考えられるほぼすべてのプラットフォームで利用でき、おそらくこれまでに使用したことがないほど多くの機能を備えています。

score 76 · Accepted Answer

これは、 Git vs. SVN (2009 年 9 月) について削除されて以来、いくつかの重複した質問に対して作成した回答のコピーです。

より良い？通常のリンクWhyGitIsBetterThanXとは別に、それらは異なります。

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

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

SVN はリビジョン管理の 3 番目の実装です。RCS、次に CVS、最後に SVNがバージョン管理されたデータのディレクトリを管理します。SVN は VCS 機能 (ラベル付けとマージ) を提供しますが、そのタグは単なるディレクトリのコピー (ブランチのようなものですが、タグディレクトリ内の何かに触れることは「想定」されていないことを除いて) であり、そのマージは依然として複雑であり、現在はメタに基づいています。 -既にマージされたものを記憶するために追加されたデータ。
Git はファイルコンテンツ管理(ファイルをマージするために作成されたツール) であり、コミットの DAG (有向非巡回グラフ)に基づいて真のバージョン管理システムに進化しました。ブランチはデータの履歴の一部です (データ自体ではありません)。 )、タグは真のメタデータです。

同じことを達成し、同じ問題を解決できるため、それらが「根本的に」異なっていないと言うのは... 非常に多くのレベルで明らかに誤りです。

複雑なマージが多数ある場合、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 に登録されません!)。

一般的な最終目標は同じかもしれませんが、それらを同じ方法で使用することはできず、同じクラスの問題 (範囲または複雑さ) を解決することもできません。

score 37 · Accepted Answer

めったに引用されない SVN の 2 つの重要な利点:

大きなファイルのサポート。コードに加えて、SVN を使用してホームディレクトリを管理しています。SVN は、私の TrueCrypt ファイルを詰まらせない唯一の VCS (配布されているかどうかにかかわらず) です (500MB 以上のファイルを効果的に処理する別の VCS がある場合は、私を修正してください)。これは、差分比較がストリーミングされるためです (これは非常に重要なポイントです)。Rsync は双方向ではないため、受け入れられません。
部分的なリポジトリ (サブディレクトリ) のチェックアウト/チェックイン。Mercurial と bzr はこれをサポートしておらず、git のサポートは制限されています。これはチーム環境では良くありませんが、ホームディレクトリから別のコンピューターで何かをチェックアウトしたい場合には非常に役立ちます。

私の経験だけです。

score 25 · Accepted Answer

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

(以下一部抜粋):

それは信じられないほど速いです。私が使用した SCM の中で、これに追いつくことができたものは他になく、Subversion、Perforce、darcs、BitKeeper、ClearCase、CVS など、多くの SCM を使用しました。
完全に配布されています。リポジトリの所有者は、私がどのように作業するかを指示することはできません。ラップトップで切断されている間にブランチを作成して変更をコミットし、後でそれを任意の数の他のリポジトリと同期できます。
同期は、多くのメディアで発生する可能性があります。WebDAV 経由の HTTP 経由、FTP 経由、またはメッセージの受信者が適用するパッチを保持する電子メールの送信による SSH チャネル。中央リポジトリは必須ではありませんが、使用できます。
ブランチは、Subversion よりもさらに安価です。ブランチの作成は、41 バイトのファイルをディスクに書き込むのと同じくらい簡単です。ブランチの削除は、そのファイルを削除するのと同じくらい簡単です。
Subversion ブランチとは異なり、ブランチは完全な履歴を保持します。奇妙なコピーを実行してコピーを実行する必要はありません。Subversion を使用しているとき、ブランチが作成される前に発生したブランチ上のファイルの履歴を見るのはいつも面倒でした。#git から: spearce: このページの SVN について 1 つ理解できません。ブランチ i SVN を作成し、履歴を参照すると、履歴全体がブランチ内のファイルに表示されました
ブランチのマージは、Git ではよりシンプルで自動化されています。Subversion では、正しいマージコマンドを生成できるように、最後にマージしたリビジョンが何であったかを覚えておく必要があります。Git はこれを自動的に行い、常に正しく行います。つまり、2 つのブランチをマージするときに間違いを犯す可能性が低くなります。
ブランチのマージは、リポジトリの適切な履歴の一部として記録されます。2 つのブランチを一緒にマージする場合、またはブランチを元のトランクにマージして戻す場合、そのマージ操作は、私がいつ実行したかとして、リポジトリ履歴の一部として記録されます。ログにすぐにある場合、誰がマージを実行したかについて議論するのは困難です。
リポジトリの作成は簡単な操作です: mkdir foo; CD フー; 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 を使用しました。

上記を読んだ後、他の人が何を言わなければならないか聞きたいですか？

score 12 · Accepted Answer

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

Git が Windows でも Unix や Mac OS X と同じように機能するようになるまでには、比較的短い時間がかかると思います (あなたが尋ねたので)。

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

score 11 · Accepted Answer

面白いことに、私は Subversion Repos でプロジェクトをホストしていますが、Git Clone コマンドを介してそれらにアクセスしています。

「 Google コードプロジェクトで Git を使用して開発する」をお読みください

Google Code は Subversion をネイティブに話しますが、開発中に Git を簡単に使用できます。「git svn」を検索すると、この慣行が広まっていることがわかります。試してみることをお勧めします。

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

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

score 9 · Accepted Answer

あなたの質問に実際に答えているわけではありませんが、分散リビジョン管理の利点が必要な場合は、Windowsを使用しているように聞こえます. Mercurial には Mac ポートもあります。

score 9 · Accepted Answer

あなたのチームが cvs や svn などのバージョンおよびソース管理ソフトウェアに既に精通している場合、単純で小規模なプロジェクト (あなたがそう主張しているようなもの) の場合は、SVN に固執することをお勧めします。私は svn に非常に慣れていますが、django で行っている現在の e コマースプロジェクトでは、git で作業することにしました (svn モードで git を使用しています。つまり、プッシュとプルを行う集中リポジトリを使用しています)。から、少なくとも 1 人の他の開発者と協力するため)。他の開発者は SVN に慣れており、他の開発者の経験は異なるかもしれませんが、私たち二人とも、この小さなプロジェクトに git を採用するのに非常に苦労しています。(それが問題であるとしても、私たちは両方ともハードコアな Linux ユーザーです。)

もちろん、走行距離は異なる場合があります。

score 8 · Accepted Answer

要点は、Git は分散型 VCS であり、Subversion は集中型の VCS であるということです。分散型 VCS は理解するのが少し難しくなりますが、多くの利点があります。この利点が必要ない場合は、Subversion を選択することをお勧めします。

もう 1 つの問題は、ツールのサポートです。使用する予定のツールでサポートされている VCS はどれですか?

編集： 3年前、私はこのように答えました：

また、Git は現時点では Cygwin またはMSYS経由でのみ Windows で動作します。Subversion は当初から Windows をサポートしていました。Windows 用の git ソリューションが機能する可能性があるため、Git のほとんどの開発者は Linux を使用しており、最初から移植性を念頭に置いていなかったため、問題が発生する可能性があります。現時点では、Windows での開発には Subversion をお勧めします。数年で、これは無関係になるかもしれません。

今、世界は少し変わりました。Git は現在、Windows で適切に実装されています。Windows で十分にテストしたわけではありませんが (このシステムはもう使用していないため)、すべての主要な VCS (SVN、Git、Mercurial、Bazaar) が適切な Windows 実装を備えていると確信しています。SVN のこの利点はなくなりました。他のポイント (集中型と分散型、およびツールサポートのチェック) は引き続き有効です。

score 7 · Accepted Answer

間違いなくsvn、Windows はせいぜい世界の二流市民だからですgit(詳細については、 http://en.wikipedia.org/wiki/Git_ (software)#Portability を参照してください)。

更新: リンクが壊れていて申し訳ありませんが、かっこを含む URI で SO を動作させることをあきらめました。【リンク修正しました。-編]

score 6 · Accepted Answer

SVN の方が広く普及しており、よく知られているため、私は SVN を選択します。

Linux ユーザーには Git の方が適していると思います。

score 4 · Accepted Answer

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

私が注意したことは、各 SVN プロジェクトは、エクスポートされない限り、成長するにつれて非常に大きなサイズのプロジェクトになるということです。一方、GIT プロジェクト (および Git データ) はサイズが非常に軽量です。

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

長い間 SVN を扱ってきましたが、開発者と私を Git に移行することを最終的に考えています。これは、共同作業やマージ作業が簡単で、ローカルコピーの変更をコミットできるという大きな利点があるためです。 SVN（サーバー上のリポジトリで時々変更をコミットする必要がある場合）とは異なり、必要に応じて、最終的にサーバー上のブランチに一度にプッシュします。

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

score 4 · Accepted Answer

これは次のようになります。

あなたの開発は直線的ですか？もしそうなら、Subversion を使い続ける必要があります。

一方、開発が線形ではない場合、つまり、さまざまな変更に対してブランチを作成し、そのような変更をメインの開発ライン (Git ではマスターブランチとして知られている) にマージする必要があることを意味します。Git はそれを行います。はるかにあなたのために。

score 4 · Accepted Answer

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

最近は SVN よりも Git を好みますが、CVS や SVN ランドから来た場合、しきい値を超えるには時間がかかります。

score 4 · Accepted Answer

SVN よりもはるかに強力だと思うので、おそらく Git を選ぶでしょう。安価なコードホスティングサービスを利用できますが、これは私にぴったりです。バックアップやメンテナンス作業を行う必要はありません。GitHubが最も明白な候補です。

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

score 3 · Accepted Answer

質問を拡大して、Git が MacOS でうまく動作するかどうか尋ねてもよろしいですか?

コメントへの返信: お知らせありがとうございます。試してみたいと思っていました。自宅のMacにインストールします。

score 3 · Accepted Answer

Bzrを試しましたか？

それはかなり良いです、コノニカル（Ubuntuを作る人々）は、市場に出回っているものが他に好きではなかったのでそれを作りました...

score 3 · Accepted Answer

これについては、YouTube に興味深いビデオがあります。Linus Torwalds 自身から: Goolge Tech Talk: Linus Torvalds on git

score 2 · Accepted Answer

他の人が指摘しているように、SVNはWindowsでは良い選択のようです。

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

score 1 · Accepted Answer

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

DVCS が配布されている場合、通常は、人々が変更をプッシュするためだけに中央サーバーを作成することを意味します。

git - SVN または Git を使用する必要がありますか?

21 に答える 21

Related

Reference