私はSubversionを数年間使用していますが、 SourceSafeを使用した後は、 Subversionが大好きです。TortoiseSVNと組み合わせると、これ以上の効果は想像できません。
それでも、Subversionには問題があり、 Gitなどの新しい種類の分散バージョン管理システムに移行する必要があると主張する開発者が増えています。
GitはSubversionでどのように改善しますか？
質問する
914068 次
30 に答える
547
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」と比較すると、Gitの「git init」はパラメーター --bare と --shared を取ることができます。リポジトリ。これには理由がありますが、複雑さが増します。「checkout」コマンドのドキュメントは、切り替えを行う人々にとって非常に紛らわしいものです。「適切な」方法は「git clone」のようですが、「git checkout」はブランチを切り替えるようです。
Git は、分散化されているときに真価を発揮します。自宅にサーバーがあり、外出先にラップトップがありますが、ここでは SVN がうまく機能しません。SVN では、リポジトリに接続していない場合、ローカル ソース コントロールを使用できません (はい、SVK について、またはリポジトリをコピーする方法について知っています)。とにかく、Git ではそれがデフォルトのモードです。ただし、これは追加のコマンドです (git commit はローカルでコミットしますが、git push origin master は master ブランチを "origin" という名前のリモートにプッシュします)。
上で述べたように、Git は複雑さを増します。リポジトリを作成する 2 つのモード、チェックアウトとクローン、コミットとプッシュ...どのコマンドがローカルで機能し、どのコマンドが「サーバー」で機能するかを知る必要があります (ほとんどの人はまだ中央の「マスター リポジトリ」が好きだと思います) ）。
また、ツールは、少なくとも Windows ではまだ不十分です。はい、Visual Studio AddIn がありますが、msysgit で git bash を使用しています。
SVN には、学習がはるかに簡単であるという利点があります。作成、コミット、およびチェックアウトの方法を知っていて、準備ができていて、後でブランチや更新などをピックアップできる場合は、リポジトリがあり、リポジトリに対するすべての変更があります。の上。
Git には、一部の開発者が常にマスター リポジトリに接続しているわけではない場合に適しているという利点があります。また、SVN よりもはるかに高速です。また、私が聞いたところによると、分岐とマージのサポートははるかに優れています (これが書かれた主な理由であるため、これは当然のことです)。
これは、Git がオープン ソース プロジェクトに完全に適しているため、インターネットで話題になっている理由も説明しています。Git をフォークし、変更を自分のフォークにコミットし、元のプロジェクトのメンテナーに変更をプルするよう依頼するだけです。Git では、これが機能します。本当に、Github で試してみてください。魔法です。
また、Git-SVN ブリッジも見られます。中央リポジトリは Subversion リポジトリですが、開発者はローカルで Git を操作し、ブリッジが変更を SVN にプッシュします。
しかし、この長い追加にもかかわらず、私は自分の核となるメッセージを支持します。Git は良くも悪くもありません。ただ違うだけです。「オフライン ソース管理」が必要で、それを学習するために余分な時間を費やす意欲があるなら、それは素晴らしいことです。しかし、厳密に集中化されたソース管理を使用している場合、および/または同僚が興味を示さないためにそもそもソース管理を導入するのに苦労している場合は、SVN のシンプルさと優れたツール (少なくとも Windows 上) が役立ちます。
于 2008-08-03T22:45:44.533 に答える
145
Git を使用すると、誰もが独自のリポジトリを持っているため、事実上何でもオフラインで行うことができます。
ブランチの作成とブランチ間のマージは非常に簡単です。
プロジェクトのコミット権を持っていなくても、独自のリポジトリをオンラインで持ち、パッチの「プッシュ リクエスト」を発行できます。あなたのパッチが好きな人なら誰でも、公式のメンテナーを含め、自分のプロジェクトにそれらを取り込むことができます。
プロジェクトをフォークして変更し、HEAD ブランチからバグ修正をマージし続けることは簡単です。
Git は、Linux カーネル開発者向けに機能します。つまり、非常に高速で (そうあるべきです)、何千ものコントリビューターに対応できます。また、Git が使用するスペースも少なくなります (Mozilla リポジトリの場合、最大で 30 分の 1 のスペース)。
Git は非常に柔軟で、非常に TIMTOWTDI です (複数の方法があります)。必要なワークフローを使用でき、Git はそれをサポートします。
最後に、Git リポジトリをホストするための優れたサイトであるGitHubがあります。
Git の欠点:
- Git にはより多くの概念とコマンドがあるため、習得するのははるかに困難です。
- リビジョンには、Subversion のようにバージョン番号がありません
- 多くの Git コマンドは不可解であり、エラー メッセージは非常にユーザーフレンドリーではない
- 優れた GUI が欠けている (優れたTortoiseSVNなど)
于 2008-08-04T00:24:15.940 に答える
110
他の回答は、Gitのコア機能（素晴らしい）を説明するのに良い仕事をしました。しかし、Gitがより適切に動作し、私の人生をより正気に保つのに役立つ小さな方法もたくさんあります。ここにいくつかのささいなことがあります：
- Gitには「clean」コマンドがあります。SVNは、ディスクに余分なファイルをダンプする頻度を考慮して、このコマンドを必死に必要としています。
- Gitには「bisect」コマンドがあります。いいね。
- SVNはすべての単一フォルダーに.svnディレクトリーを作成します（Gitは1つの.gitディレクトリーのみを作成します）。作成するすべてのスクリプト、および作成するすべてのgrepは、これらの.svnディレクトリを無視するように作成する必要があります。また、ファイルの正常なコピーを取得するためだけに、コマンド全体（ "svn export"）が必要です。
- SVNでは、各ファイルとフォルダーは異なるリビジョンまたはブランチから取得できます。最初は、この自由があるのはいいことだと思います。しかし、これが実際に意味するのは、ローカルチェックアウトを完全に台無しにする方法が無数にあるということです。（たとえば、「svn switch」が途中で失敗した場合、またはコマンドを間違って入力した場合）。そして最悪の部分は、ファイルの一部が1つの場所からのものであり、一部が別の場所からのものであるという状況に陥った場合、「svnstatus」はすべてが正常であることを示します。奇妙なことを発見するには、各ファイル/ディレクトリで「svninfo」を実行する必要があります。「gitstatus」が正常であることを示している場合は、正常であると信頼できます。
- 何かを移動または削除するときはいつでもSVNに通知する必要があります。Gitはそれを理解するだけです。
- Gitではセマンティクスを無視する方が簡単です。パターン（* .pycなど）を無視すると、すべてのサブディレクトリで無視されます。（ただし、1つのディレクトリについてのみ無視したい場合は、可能です）。SVNでは、すべてのサブディレクトリにわたるパターンを無視する簡単な方法はないようです。
- 無視ファイルを含む別の項目。Gitを使用すると、「プライベート」で設定を無視することができます（.git / info / excludeファイルを使用）。これは他の人には影響しません。
于 2008-09-26T00:18:38.620 に答える
56
「GitがXよりも優れている理由」では、Gitと他のSCMのさまざまな長所と短所について概説しています。
簡単に：
- Gitはファイルではなくコンテンツを追跡します
- ブランチは軽量で、マージは簡単です。つまり、本当に簡単です。
- それは分散されており、基本的にすべてのリポジトリはブランチです。私の意見では、Subversionを使用するよりも、同時に共同で開発する方がはるかに簡単です。また、オフライン開発も可能になります。
- 上記のリンクされたWebサイトに見られるように、ワークフローを強制することはありません。Gitで可能なワークフローは多数あります。Subversionスタイルのワークフローは簡単に模倣できます。
- Gitリポジトリは、Subversionリポジトリよりもファイルサイズがはるかに小さくなっています。数十の「.svn」リポジトリとは対照的に、「。git」ディレクトリは1つだけです（Subversion 1.7以降ではGitのような単一のディレクトリが使用されることに注意してください）。
- ステージング領域は素晴らしいです。コミットする変更を確認したり、部分的な変更をコミットしたり、その他のさまざまなことを実行したりできます。
- 「混沌とした」開発を行う場合、または他の何か（別のブランチ）で作業しているときにバグを修正したい場合、スタッシングは非常に重要です。
- 履歴を書き換えることができます。これは、パッチセットを準備し、間違いを修正するのに最適です（コミットを公開する前に）
- …そしてもっとたくさん。
いくつかの欠点があります：
- まだ多くの優れたGUIはありません。これは新しく、Subversionはずっと前から存在しているので、開発中のインターフェースがいくつかあるので、これは当然のことです。いくつかの良いものには、Mac用のTortoiseGitとGitHubが含まれます。
現在、リポジトリの部分的なチェックアウト/クローンは作成できません（開発中であると読みました）。ただし、サブモジュールのサポートがあります。Git 1.7+は、スパースチェックアウトをサポートしています。- （約1年前）そうは思わなかったのですが、学ぶのは難しいかもしれません。Gitは最近インターフェースを改善し、非常にユーザーフレンドリーです。
最も単純な使用法では、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が本当に輝いているのは、他の人と分岐して作業することです。
于 2009-02-10T04:18:46.543 に答える
54
于 2008-08-03T22:44:26.203 に答える
26
さて、配布です。ベンチマークは、それがかなり高速であることを示しています (分散された性質を考えると、差分やログなどの操作はすべてローカルであるため、この場合はもちろん非常に高速です)、作業フォルダーは小さくなります (これにはまだ驚かされます)。
Subversion やその他のクライアント/サーバーのリビジョン管理システムで作業しているときは、基本的に、リビジョンをチェックアウトしてマシン上に作業コピーを作成します。これは、リポジトリがどのように見えるかのスナップショットを表しています。更新によって作業コピーを更新し、コミットによってリポジトリを更新します。
分散バージョン管理では、スナップショットではなく、コードベース全体を使用できます。3 か月前のバージョンとの差分を作成しますか? 問題ありません。3 か月前のバージョンがまだコンピュータにあります。これは、処理が高速になったことを意味するだけでなく、中央サーバーから切断されていても、慣れ親しんだ操作の多くを実行できます。つまり、特定のリビジョンのスナップショットだけでなく、コードベース全体を取得できます。
Git はハードドライブの多くのスペースを占めると思われるかもしれませんが、私が見たいくつかのベンチマークから、実際にはそれよりも少なくてすみます。方法を聞かないでください。つまり、これは Linus によって構築されたもので、ファイルシステムについて多少は知っていると思います。
于 2008-08-03T22:47:42.703 に答える
22
私が DVCS について気に入っている主な点は次のとおりです。
- 壊れたものをコミットできます。あなたが公開するまで他の人はそれらを見ないので、それは問題ではありません. パブリッシュ時間はコミット時間とは異なります。
- このため、より頻繁にコミットできます。
- 完全な機能をマージできます。この機能には独自のブランチがあります。このブランチのすべてのコミットは、この機能に関連します。CVCS で実行できますが、DVCS がデフォルトです。
- 履歴を検索できます (関数が変更された時期を見つける)
- 誰かがメイン リポジトリを台無しにした場合、プルを元に戻すことができます。エラーを修正する必要はありません。マージをクリアするだけです。
- 任意のディレクトリにソース管理が必要な場合は、次のようにします: git init. コミット、変更の取り消しなどを行うことができます...
- 高速です（Windowsでも）
比較的大規模なプロジェクトの主な理由は、ポイント 3 によって作成されたコミュニケーションの改善です。その他は素晴らしいボーナスです。
于 2008-09-04T11:06:59.397 に答える
15
面白いことに、私は Subversion Repos でプロジェクトをホストしていますが、Git Clone コマンドを介してそれらにアクセスしています。
「 Google コード プロジェクトで Git を使用して開発する」をお読みください
Google Code は Subversion をネイティブに話しますが、開発中に Git を簡単に使用できます。「git svn」を検索すると、この慣行が広まっていることがわかります。ぜひ試してみることをお勧めします。
Svn リポジトリで Git を使用すると、次のような利点があります。
- 複数のマシンに分散して作業し、それらのマシンからのコミットとプルを行うことができます
- 他の人がチェックアウトできる中央のsvnリポジトリがあります
backup/public - そして、Git を自由に使用できます。
于 2008-10-02T13:05:58.340 に答える
11
ここでのすべての回答は予想どおり、プログラマ中心ですが、会社がソース コードの外でリビジョン管理を使用するとどうなるでしょうか? バージョン管理の恩恵を受けるソースコードではないドキュメントがたくさんあり、別の CMS ではなく、コードの近くに配置する必要があります。ほとんどのプログラマーは孤立して働いているのではなく、チームの一員として企業のために働いています。
それを念頭に置いて、クライアント ツールとトレーニングの両方で、Subversion と git の使いやすさを比較してください。分散リビジョン管理システムが、プログラマーでない人にとって使いやすく、説明しやすいというシナリオは見当たりません。私が間違っていることが証明されれば、git を評価して、プログラマーではないバージョン管理を必要とする人々に受け入れられることを実際に期待できるからです。
それでも、なぜ集中型から分散型のリビジョン管理システムに移行する必要があるのかを経営陣から尋ねられた場合、正直に答えるのは難しいでしょう。なぜなら、それは必要ないからです。
免責事項: 私は早い段階 (v0.29 頃) に Subversion に興味を持ったので、明らかに偏見がありますが、それ以来私が働いてきた企業は、私が Subversion の使用を奨励しサポートしてきたため、私の熱意から恩恵を受けています。これは、ほとんどのソフトウェア会社で起こっていることだと思います。非常に多くのプログラマーが git の流行に飛び乗っているため、ソース コード以外でバージョン管理を使用する利点を逃している企業がどれほどあるのでしょうか? チームごとに別々のシステムを使用している場合でも、メンテナンス、ハードウェア、およびトレーニングの要件が増える一方で、(統合された) 問題追跡の統合など、いくつかの利点を逃しています。
于 2009-10-13T07:01:50.840 に答える
8
私を苛立たせているSubVersionの1つは、プロジェクトの各ディレクトリに独自のフォルダを配置するのに対し、gitはルートディレクトリに1つしか配置しないことです。それはそれほど大したことではありませんが、そのような小さなことは合計されます。
もちろん、SubVersionにはTortoiseがあり、これは[通常]非常に優れています。
于 2008-08-22T15:24:44.907 に答える
8
Subversion / GIT に関する David Richards WANdisco ブログ
GIT の出現により、GIT 以外のものはすべてがらくただと考える一種の DVCS 原理主義者 (「Gitterons」) が生まれました。Gitterons は、ソフトウェア エンジニアリングは自分たちの島で行われると考えているようで、ほとんどの組織がシニア ソフトウェア エンジニアだけを採用しているわけではないことを忘れがちです。それは問題ありませんが、それは他の市場の考え方ではありません。私はそれを証明できることをうれしく思います: GIT は、最後に見たところ、市場の 3% 未満でしたが、Subversion は 500 万人のユーザーと約半分のユーザーを抱えていました。市場全体。
私たちが目にした問題は、Gitterons が Subversion に対して (安価な) ショットを発射していたことです。「Subversion はとても [遅い / くだらない / 制限的 / いい匂いがしない / おかしな目で私を見る] そして今、私は GIT を取得し、[私の人生ではすべてがうまくいっています / 私の妻は妊娠しました / その後ガールフレンドができました」 30年間の挑戦/ブラックジャックテーブルで6回勝ちました]。あなたは絵を手に入れます。
于 2010-09-17T18:22:30.390 に答える
7
Git を使用すると、分岐とマージも非常に簡単になります。Subversion 1.5 ではマージ トラッキングが追加されましたが、Git の方が優れています。Git を使用すると、分岐は非常に高速かつ安価になります。これにより、新しい機能ごとにブランチを作成することがより実現可能になります。Oh および Git リポジトリは、Subversion と比較して、ストレージ スペースに関して非常に効率的です。
于 2008-08-09T03:22:14.510 に答える
6
Easy Gitには、 GitとSVNの実際の使用法を比較したすばらしいページがあり、SVNと比較してGitが実行できる（またはより簡単に実行できる）ことを理解できます。（技術的には、これはGitの上に軽量のラッパーであるEasy Gitに基づいています。）
于 2008-08-22T15:19:57.163 に答える
6
何かを行うために必要な使いやすさ/手順がすべてです。
PC/ラップトップで 1 つのプロジェクトを開発している場合、セットアップと使用がはるかに簡単な git の方が適しています。サーバーは必要ありませんし、マージを行うときにリポジトリの URL を入力し続ける必要もありません。
2人だけなら、お互いに押したり引いたりできるので、gitの方が簡単だと思います。
ただし、それを超えたら、「専用の」サーバーまたは場所を設定する必要があるため、Subversion を使用します。
SVN と同様に git でもこれを行うことができますが、git の利点は、中央サーバーと同期するための追加の手順を実行する必要性よりも優先されます。SVN ではコミットするだけです。git では、git commit してから git push する必要があります。追加の手順は、あまりにも多くのことを行うだけなので、煩わしくなります。
SVN には優れた GUI ツールという利点もありますが、git エコシステムは急速に追いついているように見えるので、長期的には心配する必要はありません。
于 2008-08-03T23:38:05.113 に答える
5
私はGitが好きです。それは、中規模から大規模のチームでコミュニケーション開発者から開発者へのコミュニケーションに実際に役立つからです。分散バージョン管理システムとして、プッシュ/プルシステムを通じて、開発者が単一のプロジェクトで作業する開発者の大規模なプールを管理するのに役立つソースコードエコシステムを作成するのに役立ちます。
たとえば、5人の開発者を信頼し、リポジトリからコードをプルするだけだとします。これらの開発者はそれぞれ、コードをプルする場所から独自の信頼ネットワークを持っています。したがって、開発は、コードの責任が開発コミュニティ間で共有される開発者の信頼構造に基づいています。
もちろん、ここで他の回答に記載されている他の利点があります。
于 2008-10-05T16:52:34.693 に答える
5
Git と DVCS は一般に、開発者がそれぞれ独自のブランチを持っているため、互いに独立して多くのコーディングを行う場合に最適です。ただし、他の誰かからの変更が必要な場合は、彼女は自分のローカル リポジトリにコミットする必要があり、その変更セットをあなたにプッシュするか、あなたが彼女からプルする必要があります。
私自身の推論では、集中型リリースのようなことを行う場合、DVCS によって QA やリリース管理が難しくなると思います。誰かが他の全員のリポジトリからプッシュ/プルを実行し、以前の最初のコミット時に解決されていた競合を解決し、ビルドを実行してから、他のすべての開発者にリポジトリを再同期させる責任を負う必要があります。
もちろん、これらはすべて人間のプロセスで対処できます。DVCS は、いくつかの新しい利便性を提供するために、集中型バージョン管理によって修正されたものを壊しました。
于 2008-08-03T23:08:23.580 に答える
4
いくつかの回答がこれらをほのめかしていますが、私は2つの点を明確にしたいと思います:
1) 選択的なコミットを実行する機能 (例: git add --patch)。作業ディレクトリに同じ論理変更の一部ではない複数の変更が含まれている場合、Git を使用すると、変更の一部のみを含むコミットを非常に簡単に作成できます。Subversion では、それは困難です。
2) 変更を公開せずにコミットする機能。Subversion では、コミットはすぐに公開されるため、取り消すことはできません。これにより、開発者が「早期にコミットし、頻繁にコミットする」という能力が大幅に制限されます。
Git は単なる VCS ではありません。また、パッチを開発するためのツールでもあります。Subversion は単なる VCS です。
于 2009-08-07T14:59:17.853 に答える
4
Subversionは問題ないと思います..マージを開始するまで..または複雑なことをする..またはSubversionが複雑だと思うことをするまで（特定のファイルでどのブランチが混乱したか、変更が実際にどこから来たか、コピー＆ペーストを検出するクエリを実行するなど）など）...
GIT の主な利点はオフラインでの作業であると言って、勝者の答えには同意しません。これは確かに便利ですが、私のユースケースでは追加のようなものです。SVK はオフラインでも作業できますが、学習時間をどれに投資するかについては疑問の余地がありません)。
それは信じられないほど強力で高速であり、概念に慣れた後は非常に便利です (そうです、その意味で: ユーザーフレンドリーです)。
マージ ストーリーの詳細については、次を参照してください: Using git-svn (or similar) *just* to help out with an svn merge?
于 2010-07-27T15:40:33.973 に答える
3
これは間違った質問です。少なくとも一部のユースケースでは、git の疣贅に焦点を当てて、表向きはなぜ Subversion の方が優れているのかという議論を立てるのは簡単です。git は元々、低レベルのバージョン管理構築セットとして設計され、Linux 開発者向けのバロック様式のインターフェイスを備えているという事実により、聖戦が牽引力を獲得し、正当性を認識しやすくなっています。Git 支持者は、何百万ものワークフローの利点でドラムを叩きます。すぐに、議論全体が集中型か分散型かという枠組みになり、エンタープライズ svn ツール コミュニティの利益になります。これらの企業は、通常、エンタープライズにおける Subversion の優位性について最も説得力のある記事を掲載しています。
しかし、ここに問題があります。Subversion はアーキテクチャ上の行き止まりです。
git を使って一元化されたサブバージョンの代替品を簡単に構築できますが、svn は 2 倍以上の期間存在しているにもかかわらず、基本的なマージ追跡でさえも git と同じように機能することはありませんでした。この基本的な理由の 1 つは、ブランチをディレクトリと同じにするという設計上の決定です。なぜ彼らが最初にこのようにしたのかはわかりませんが、部分的なチェックアウトが非常に簡単になることは確かです。残念ながら、履歴を適切に追跡することもできなくなります。明らかに、通常のディレクトリからブランチを分離するために Subversion リポジトリ レイアウト規則を使用することになっています。また、svn はいくつかのヒューリスティックを使用して、日常のユース ケースで機能するようにします。しかし、これはすべて、非常に貧弱で制限的な低レベルの設計上の決定を強調しているだけです。(ディレクトリごとの差分ではなく) リポジトリごとの差分を実行できることは、バージョン管理システムの基本的かつ重要な機能であり、内部を大幅に簡素化し、その上にスマートで便利な機能を構築できるようにします。サブバージョンを拡張するために費やされた努力の量を見ることができますが、マージ解決などの基本的な操作に関して、現在の VCS の現在の作物からどれだけ遅れているかがわかります。
Subversion が予見可能な将来において十分に優れているとまだ信じている人に向けて、私から心からのアドバイスをお伝えします。
Subversion は、RCS と CVS の過ちから学んだ新しい種類の VCS に追いつくことはありません。彼らがリポジトリモデルを一から作り直さない限り、技術的に不可能ですが、それは本当にsvnではないでしょうか? 最新の VCS の機能がないとどれだけ考えていても、Subversion の落とし穴からあなたを無知で守ることはできません。その多くは、他のシステムでは不可能または簡単に解決できる状況です。
ソリューションの技術的な劣等性が svn の場合のように明確であることは非常にまれです。確かに、win-vs-linux や emacs-vs-vi についてそのような意見を述べるつもりはありませんが、この場合はそうですソース管理は開発者にとって非常に基本的なツールであるため、明確に述べておく必要があると思います。組織上の理由で svn を使用する必要があるにもかかわらず、私はすべての svn ユーザーに、最新の VCS は大規模なオープンソース プロジェクトにのみ役立つという誤った信念を論理的に構築させないようにお願いします。開発作業の性質に関係なく、プログラマーであれば、より優れた設計の VCS (Git、Mercurial、Darcs など) の使用方法を学べば、より効果的なプログラマーになることができます。
于 2011-05-29T17:30:50.897 に答える
3
中央サーバーと常に通信する必要がないという事実のおかげで、ほぼすべてのコマンドが 1 秒未満で実行されます (SSH 接続を初期化する必要があるため、明らかに git push/pull/fetch の方が遅くなります)。分岐ははるかに簡単です (分岐するための 1 つの単純なコマンド、マージするための 1 つの単純なコマンド)
于 2008-08-30T12:01:09.527 に答える
3
中央リポジトリの水を汚すことなく、Git でソース コードのローカル ブランチを管理できることを心から気に入っています。多くの場合、Subversion サーバーからコードをチェックアウトし、これを行うためだけにローカルの Git リポジトリを実行します。また、Git リポジトリを初期化してもファイルシステムが煩わしい .svn フォルダーの集まりで汚染されないことも素晴らしいことです。
また、Windows ツールのサポートに関しては、TortoiseGit は基本的な機能を非常にうまく処理しますが、ログを表示する必要がない限り、コマンド ラインを使用することを好みます。コミットログを読むときに Tortoise{Git|SVN} が役立つ方法が本当に気に入っています。
于 2010-02-10T22:54:35.410 に答える
2
Subversionは非常に使いやすいです。私はここ数年、問題や何かが期待どおりに機能しないことを発見したことはありません。また、多くの優れたGUIツールがあり、SVN統合のサポートは大きいです。
Gitを使用すると、より柔軟なVCSを利用できます。すべての変更をコミットするリモートリポジトリでのSVNと同じように使用できます。ただし、ほとんどオフラインで使用して、変更をリモートリポジトリにプッシュすることもできます。しかし、Gitはより複雑で、学習曲線が急になっています。私は初めて間違ったブランチにコミットしたり、間接的にブランチを作成したり、間違いに関する情報があまりないエラーメッセージを受け取ったり、より良い情報を得るためにGoogleで検索する必要があることに気付きました。マーカーの置換（$ Id $）のような簡単なことは機能しませんが、GITには、独自のスクリプトをマージするための非常に柔軟なフィルタリングとフックメカニズムがあるため、必要なものすべてを取得できますが、より多くの時間とドキュメントを読む必要があります;）
ローカルリポジトリでほとんどオフラインで作業している場合、ローカルマシンで何かが失われた場合でも、バックアップはありません。SVNを使用すると、ほとんどの場合、別のサーバーでのバックアップと同時にリモートリポジトリを操作します... Gitも同じように機能しますが、これは、SVN2のようなものを持つLinusの主な目標ではありませんでした。Linuxカーネル開発者と分散バージョン管理システムのニーズのために設計されました。
GitはSVNよりも優れていますか？一部のバージョン履歴とバックアップメカニズムのみを必要とする開発者は、SVNを快適に利用できます。ブランチで頻繁に作業する開発者、同時により多くのバージョンをテストする開発者、またはほとんどオフラインで作業する開発者は、Gitの機能の恩恵を受けることができます。SVNにはないスタッシングのような非常に便利な機能がいくつかあり、生活を楽にすることができます。しかし一方で、すべての人がすべての機能を必要とするわけではありません。だから私はSVNの死者を見ることができません。
Gitにはより優れたドキュメントが必要であり、エラー報告はより役立つはずです。また、既存の便利なGUIはめったにありません。今回は、ほとんどのGit機能（git-cola）をサポートするLinux用のGUIを1つだけ見つけました。Eclipse統合は機能していますが、公式にはリリースされておらず、公式の更新サイトはありません（トランクから定期的にビルドされる一部の外部更新サイトのみhttp://www.jgit.org/updates）したがって、今日Gitを使用する最も好ましい方法コマンドラインです。
于 2009-10-13T13:14:45.567 に答える
2
優れたGitGUIを探している人にとって、SyntevoSmartGitは優れたソリューションかもしれません。独自仕様ですが、非営利目的で無料で使用でき、Windows / Mac / Linuxで動作し、ある種のgit-svnブリッジを使用してSVNをサポートしていると思います。
于 2011-03-09T14:05:56.953 に答える
2
SourceGearのEricSinkは、分散バージョン管理システムと非分散バージョン管理システムの違いに関する一連の記事を書きました。彼は、最も人気のあるバージョン管理システムの長所と短所を比較しています。非常に興味深い読書。
記事は彼のブログ、www.ericsink.comで見つけることができます：
于 2009-10-13T13:36:01.670 に答える
1
まず、同時バージョン管理は簡単に解決できる問題のようです。まったくそうではありません。ともかく...
SVNは非常に直感的ではありません。Gitはさらに悪化します。[皮肉な憶測]これは、同時バージョン管理のような難しい問題が好きな開発者が、優れたUIを作成することにあまり関心がないためかもしれません。[/皮肉-憶測]
SVNサポーターは、分散バージョン管理システムは必要ないと考えています。私もそう思いました。しかし、Gitを独占的に使用している今、私は信者です。これで、バージョン管理は、プロジェクトのためだけに機能するのではなく、私とチーム/プロジェクトのために機能します。ブランチが必要なときは、ブランチします。サーバー上に対応するブランチがあるブランチである場合もあれば、ない場合もあります。私が研究しなければならない他のすべての利点は言うまでもありません（現代のバージョン管理システムであるUIの難解でばかげた欠如に部分的に感謝します）。
于 2010-01-03T12:45:36.960 に答える
1
私は最近Gitの土地に住んでいて、個人的なプロジェクトには気に入っていますが、スタッフからの要求の考え方が変わったため、差し迫ったメリットがなければ、Subversionからまだ作業プロジェクトをGitに切り替えることはできません。さらに、私たちが社内で実行している最大のプロジェクトは、 svn：externalsに非常に依存しています。これは、これまで見てきたことから、Gitではそれほどうまくシームレスに機能しません。
于 2010-04-25T21:35:23.513 に答える
1
SubversionがGitよりも優れていると思う理由（少なくとも私が取り組んでいるプロジェクトでは）、主にその使いやすさとワークフローの簡素化のためです。
http://www.databasesandlife.com/why-subversion-is-better-than-git/
于 2010-10-22T16:25:05.737 に答える
1
http://subversion.wandisco.com/component/content/article/1/40.html
開発者の間では、SVN対と言ってもかなり安全だと思います。Gitの議論はしばらくの間激怒しており、誰もがどちらが優れているかについて独自の見解を持っています。これは、2010年以降のSubversionに関するウェビナーでの質問でも取り上げられました。
オープンソースのディレクターであり、SubversionCorporationの社長であるHyrumWrightが、SubversionとGitの違い、および他の分散バージョン管理システム（DVCS）について話します。
彼はまた、Working Copy Next Generation（WC-NG）など、Subversionの今後の変更についても話します。これにより、多くのGitユーザーがSubversionに戻ると考えています。
彼のビデオを見て、このブログにコメントするか、フォーラムに投稿して、あなたの考えを教えてください。登録は簡単で、ほんの一瞬です！
于 2010-02-10T18:51:32.180 に答える
1
現在、Windows の Git は十分にサポートされています。
GitExtensions を確認してください = http://code.google.com/p/gitextensions/
Windows Git エクスペリエンスを向上させるためのマニュアル。
于 2010-02-10T16:29:29.163 に答える