•  03-07-2019
  •  | 
  •  

質問

GitとCVSバージョン管理システムの違いは何ですか？

私は10年以上CVSを喜んで使用してきましたが、今ではGitの方がはるかに優れていると言われています。誰かが2つの違いが何であるか、なぜ一方が他方より優れているのか説明していただけますか？

役に立ちましたか？

解決

主な違いは、（他の応答ですでに述べたように）CVSは（古い）集中型バージョン管理システムであるのに対し、Gitは配布されていることです。

ただし、1人の開発者（1台のマシン）でバージョン管理を使用している場合でも、GitとCVSにはいくつかの違いがあります：

  • リポジトリのセットアップ。 Gitはリポジトリをプロジェクトの最上位ディレクトリの .git ディレクトリに保存します。 CVSでは、さまざまなプロジェクト（モジュール）のバージョン管理情報を保存するための中心的な場所であるCVSROOTを設定する必要があります。ユーザー向けのこの設計の結果は、既存のソースをバージョン管理にインポートすることは、「git init＆amp;＆amp; git add。 ＆amp;＆amp; git commit＆quot; Gitでは、 CVSのより複雑な。

  • 原子操作。 CVSは最初はファイルごとのRCSバージョン管理システムに関する一連のスクリプトであったため、CVSではコミット（およびその他の操作）はアトミックではありません。リポジトリの操作が途中で中断された場合、リポジトリは一貫性のない状態のままになる可能性があります。 Gitでは、すべての操作はアトミックです。全体として成功するか、変更なしで失敗します。

  • チェンジセット。 CVSの変更はファイルごとに行われますが、Gitの変更（コミット）は常にプロジェクト全体を参照します。これは非常に重要なパラダイムシフトです。この結果の1つは、Gitで変更を元に戻す（元に戻す変更を作成する）または全体変更を元に戻すのが非常に簡単なことです。他の結果として、CVSでは部分的なチェックアウトが簡単ですが、Gitでは現在ほとんど不可能です。変更がファイルごとにグループ化されているという事実は、CVSのコミットメッセージ用のGNU Changelog形式の発明につながりました。 Gitユーザーは異なる規則を使用し（一部のGitツールも想定）、変更を説明（要約）する1行、空行、変更の詳細な説明が続きます。

  • リビジョン/バージョン番号の命名。 CVSの変更はファイルごとであるという事実に関連する別の問題があります：バージョン番号（キーワード展開で時々見られるように、以下を参照）は1.4のようにファイルが変更された回数を反映します。 Gitでは、プロジェクト全体（各コミット）の各バージョンには、SHA-1 idで指定された一意の名前があります。通常、コミットを識別するには最初の7〜8文字で十分です（分散バージョン管理システムのバージョンに単純な番号付けスキームを使用することはできません。これには中央の番号付け権限が必要です）。 CVSでは、プロジェクト全体の状態を参照するバージョン番号または記号名を使用するには、タグを使用します。プロジェクトの一部のバージョンに「v1.5.6-rc2」などの名前を使用する場合、Gitでも同じことが言えますが、Gitのタグははるかに使いやすいです。

  • 簡単なブランチ。私の意見では、CVSのブランチは非常に複雑であり、対処が困難です。リポジトリブランチ全体の名前を持つようにブランチをタグ付けする必要があります（ファイルごとの処理のために正しく覚えていれば、失敗する場合もあります）。それに加えて、CVSには merge tracking がないため、マージとブランチポイントを覚えておくか、手動でタグ付けし、＆quot; cvs update -j＆quot;の正しい情報を手動で提供する必要があります。ブランチをマージします。ブランチを不要に使用するのが難しくなります。 Gitでは、ブランチの作成とマージは非常に簡単です。 Gitはそれ自体で必要な情報をすべて記憶します（したがって、ブランチのマージは＆quot; git merge branchname ＆quot;と同じくらい簡単です）...分散開発は自然に複数のブランチにつながるため、必要でした。

    これは、トピックブランチを使用できることを意味します。再ブランチ。

  • 追跡の名前を変更（およびコピー）。ファイルの名前変更はCVSではサポートされていないため、手動で名前を変更すると履歴が2つに分割されたり、名前を変更する前にプロジェクトの状態を正しく回復できない無効な履歴になったりする場合があります。 Gitは、コンテンツとファイル名の類似性に基づいて、ヒューリスティックな名前変更検出を使用します（このソリューションは実際にうまく機能します）。ファイルのコピーの検出を要求することもできます。つまり：

    • 指定されたコミットを調べると、ファイルの名前が変更されたという情報が得られます
    • マージでは、名前の変更が正しく考慮されます（たとえば、ファイルの名前が1つのブランチでのみ変更された場合）
    • ＆quot; git blame＆quot;（より良い）ファイルの内容の行ごとの履歴を表示するツールである＆quot; cvs annotate＆quot;に相当するものは、名前の変更でもコードの動きを追跡できます

  • バイナリファイル。 CVSはバイナリファイル（画像など）のサポートが非常に限定されているため、ユーザーは追加時にバイナリファイルを明示的にマークする必要があります（または後で＆quot; cvs admin＆quot;を使用するか、ラッパーを使用してファイル名に基づいて自動的に行う）。行末変換およびキーワード拡張によるバイナリファイルの変換。 Gitは、CNU diffや他のツールが行うのと同じ方法で、コンテンツに基づいてバイナリファイルを自動的に検出します。 gitattributesメカニズムを使用してこの検出をオーバーライドできます。さらに、バイナリファイルは 'safecrlf'のデフォルト（および、配布によってはデフォルトでオンになる場合がありますが、行末変換を要求する必要があるという事実）とその（制限付き）キーワードのおかげで、回復不能なマングリングに対して安全です拡張はGitの厳密な「オプトイン」です。

  • キーワード展開。 Gitは、CVS（デフォルト）と比較して、非常に限られたキーワードセットを提供します。これは2つの事実によるものです。Gitの変更はファイルごとではなくリポジトリごとであり、Gitは他のブランチへの切り替えや履歴内の他のポイントへの巻き戻し時に変更されなかったファイルの変更を回避します。 Gitを使用してリビジョン番号を埋め込む場合は、ビルドシステムを使用してこれを行う必要があります。 LinuxカーネルソースおよびGitソースのGIT-VERSION-GENスクリプトの次の例。

  • コミットの修正。 Gitなどの分散VCSでは、公開の行為はコミットの作成とは異なるため、他のユーザーに迷惑をかけることなく、履歴の未公開部分を変更（編集、書き換え）できます。特に、コミットメッセージのタイプミス（またはその他のエラー）、またはコミットのバグに気付いた場合は、単に「git commit --amend」を使用できます。これはCVSでは不可能です（少なくとも、激しいハッカーなしでは不可能です）。

  • その他のツール。 GitはCVSよりもはるかに多くのツールを提供します。より重要なものの1つは＆quot; git bisect ＆quot;バグを導入したコミット（リビジョン）を見つけるために使用できます。コミットが小規模で自己完結型である場合、バグがどこにあるかを見つけるのはかなり簡単です。

少なくとも1人の他の開発者とコラボレーションしている場合、GitとCVSの間には次のような違いもあります。

  • マージ前にコミット Gitは、CVSのように merge-before-commit ではなく commit-before-merge を使用します（または update-then-commit ）。ファイルの編集中に、他の誰かが同じブランチで新しいコミットを作成して新しいコミット（新しいリビジョン）を作成する準備をしていて、現在リポジトリにある場合、CVSは、コミットを許可する前にまず作業ディレクトリを更新し、競合を解決するように強制します。これはGitには当てはまりません。最初にコミットし、状態をバージョン管理に保存してから、他の開発者の変更をマージします。他の開発者にマージを実行して競合を解決するよう依頼することもできます。

    事前に線形の履歴を持ち、マージを回避するには、＆quot; git rebase＆quot;を介して commit-merge-recommit ワークフローをいつでも使用できます。 （および＆quot; git pull --rebase＆quot;）。これは、更新された状態の上で変更をリプレイするという点でCVSに似ています。ただし、常に最初にコミットします。

  • 中央リポジトリは不要 Gitを使用すると、変更をコミットする単一の場所を中央に持つ必要がありません。各開発者は独自のリポジトリ（またはより優れたリポジトリ：開発を行うプライベートリポジトリ、および公開済みの準備が整った部分を公開するリポジトリ）を持つことができ、各リポジトリから他のリポジトリからプル/フェッチすることができます対称的なファッション。一方、大規模なプロジェクトでは、誰もがそこからプル（変更を取得）する socially 定義/指定された中央リポジトリを持つことが一般的です。

最終的に、Gitは、多数の開発者とのコラボレーションが必要な場合、さらに多くの可能性を提供します。以下に、GitのCVSとプロジェクトのさまざまな段階と位置の違いを示します（CVSまたはGitを使用したバージョン管理下）：

  • lurker 。プロジェクトから最新の変更を取得することにのみ関心がある場合（変更を伝播しない）、またはプライベート開発を行う（元のプロジェクトに貢献しない）。または、独自のプロジェクトの基礎として外国のプロジェクトを使用します（変更はローカルであり、公開することは意味がありません）。

    Gitは、ここで 認証されていない匿名 カスタムの効率的な git：// プロトコルを介した読み取り専用アクセスをサポートしています。 code> DEFAULT_GIT_PORT （9418）プレーンHTTPを使用できます。

    CVSの読み取り専用アクセスの最も一般的なソリューション（私が理解しているように）は、 CVS_AUTH_PORT の「pserver」プロトコルの ゲストアカウント です。 （2401）、通常「匿名」と呼ばれます。そして、空のパスワードで。資格情報はデフォルトで $ HOME / .cvspass ファイルに保存されるため、一度だけ提供する必要があります。それでも、これは少しの障壁です（ゲストアカウントの名前を知っているか、CVSサーバーメッセージに注意する必要があります）および迷惑です。

  • フリンジ開発者（リーフコントリビューター）。 OSSで変更を伝達する1つの方法は、電子メールでパッチを送信することです。これは、（多かれ少なかれ）偶発的な開発者であり、単一の変更または単一のバグ修正を送信する場合の最も一般的なソリューションです。ところで。パッチの送信は、電子メールだけでなく、レビューボード（パッチレビューシステム）または同様の手段を介して行われます。

    Gitは、送信者（クライアント）と管理者（サーバー）の両方にこの伝播（公開）メカニズムを支援するツールを提供します。メールで変更を送信したい人のために、＆quot; git rebase ＆quot; （または＆quot; git pull --rebase＆quot;）ツールを使用して、現在のアップストリームバージョンの上に独自の変更を再生します。したがって、変更は現在のバージョンの上にあり（最新）、＆quot; git format-patch ＆quot;コミットメッセージ（および作成者）を含む電子メールを作成するには、（拡張された）統一されたdiff形式（および確認しやすいようにdiffstatの形式）に変更します。メンテナーは、＆quot; git am ＆quot;。

    CVSはそのようなツールを提供していません。「cvs diff」を使用できます。 /＆cv; cvs rdiff＆quot;変更を生成し、GNUパッチを使用して変更を適用しますが、私が知る限り、コミットメッセージの適用を自動化する方法はありません。 CVSは使用することを意図していた

他のヒント

Gitは DVCS です。CVSは一元化されています。簡単に説明すると、複数の可能なリポジトリの any に接続していないときにバージョン管理のすべての利点が得られ、さらに操作が高速になります。

Git Webサイトはおそらくこれを最もよく説明しています。

私のペット機能は、オフラインのときにコミットを実行できます。そして、速度、押したり引いたりする以外のすべてが起こる速すぎる燃える速度。 （また、これらの操作は非破壊的な設計であるため、中央レポが遅れている場合、コーヒーをつかむときにプッシュ/プルすることができます。）別の良い点は、バッテリーが付属していることです：組み込みの gitk は十分な履歴ビューア。 git gui は、十分なコミットツールです。出力の色付けでは、 git add -i 、 git add -p 、 git rebase -i は十分にインタラクティブなインターフェースです。 git daemon と git instaweb は、中央リポジトリを使いたくない/いじれない場合のアドホックコラボレーションに十分です。

私も10年以上、ほとんどcvsのユーザーです。gitも好きですが、やがてそれを好むようになりますが、現在取り組んでいるプロジェクトのほとんどはcvsまたはsvnを使用しています。私が仕事をしている場所では、ファイアウォールを介してgit-holeをパンチできると確信している官僚主義を取得していないようです。

cvsを他の方法よりも優れたものにしているものはcvspsであり、もう1つはAndrew Mortonのパッチスクリプトまたはキルトです。 Cvspsでは、キルト中にコミットの複数のファイルを単一のパッチに再構成することができ（したがって、CVSから「変更セット」を抽出できます）、またはAndrew Mortonのパッチスクリプトを使用して、賢明な「変更セット」をコミットできます。 cvsを非常に簡単かつ快適に使用して、コミットする前に複数の物を同時に分離しながら、複数の物に同時に取り組むことができます。 CVSには癖がありますが、私はそれらのほとんどに慣れています。

＆quot; CVSをx年以上にわたって使用すること ''は興味深いアイデアです:-)これは、大量のコピーを保持することからの大きなステップアップですが、...

おかしなことに慣れているか、あまりブランチやマージをしないでください。より悪い可能性があります。

組織内の人々はcvsの制限に慣れており、それに応じて業務慣行も適応しています;

たとえば、一度に1つのパッケージで複数の開発者が作業することはなく、緊急時などにのみ分岐を使用します。

基本原則は、何かが難しいほど、それをやる人が減ることです。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top