バージョン管理

バージョン管理(リビジョン管理、ソース管理、ソース コード管理とも呼ばれる) は、コンピューターファイル(主にソース コードテキスト ファイルですが、一般的にはあらゆる種類のファイル)のさまざまなバージョンを履歴として管理、整理、追跡するソフトウェア エンジニアリングの手法です。

バージョン管理はソフトウェア構成管理の構成要素である。^{[ 1 ]}

バージョン管理システムは、バージョン管理を自動化するソフトウェアツールです。また、ワードプロセッサ、スプレッドシート、共同ウェブドキュメント^{[ 2 ]}、コンテンツ管理システム（ Wikipediaのページ履歴など）などの一部のシステムに、バージョン管理が機能として組み込まれている場合もあります。

バージョン管理には、古いバージョンを表示したり、ファイルを以前のバージョンに 戻したりするオプションが含まれています。

概要

チームがソフトウェアを開発する際、同じソフトウェアの複数のバージョン を展開し、異なる開発者が1つまたは複数の異なるバージョンで同時に作業することが一般的です。ソフトウェアのバグや機能は、多くの場合、特定のバージョンにのみ存在します（プログラムの開発中にいくつかの問題が修正され、他の問題が導入されるため）。したがって、バグの特定と修正のためには、ソフトウェアの異なるバージョンを取得して実行し、どのバージョンで問題が発生しているかを特定できることが非常に重要です。また、ソフトウェアの2つのバージョンを同時に開発する必要がある場合もあります。たとえば、1つのバージョンではバグが修正されているが新しい機能は追加されておらず（ブランチ）、もう1つのバージョンでは新しい機能が開発されている（トランク） などです

最も単純なレベルでは、開発者はプログラムの異なるバージョンのコピーを複数保持し、それらに適切なラベルを付けるだけで済みます。この単純なアプローチは、多くの大規模ソフトウェアプロジェクトで採用されてきました。この方法は確かに有効ですが、ほぼ同一のプログラムのコピーを多数維持する必要があるため、非効率的です。開発者には高度な自己規律が求められ、ミスにつながることも少なくありません。コードベースは同一であるため、複数の開発者に読み取り・書き込み・実行権限を付与する必要があり、コードベースが侵害されないように権限を管理する担当者の負担が加わり、複雑さが増します。その結果、リビジョン管理プロセスの一部またはすべてを自動化するシステムが開発されてきました。これにより、ほとんどの操作手順が抽象化され、一般ユーザーから隠蔽されます。

さらに、ソフトウェア開発、法務・ビジネス実務、その他の環境において、単一のドキュメントやコードスニペットを複数のチームメンバーが編集することがますます一般的になっています。チームメンバーは地理的に分散しており、異なる、あるいは相反する利益を追求している場合もあります。このような状況では、ドキュメントやコードの変更を追跡し、その所有権を管理する高度なリビジョン管理が非常に役立つ場合があり、場合によっては不可欠となることもあります。

リビジョン管理は、Unixシステム内またはUnixシステム上に格納されるような設定ファイルの変更も追跡できます。これにより、システム管理者は変更内容を容易に追跡し、必要に応じて以前のバージョンにロールバックできるようになります。 /etc/usr/local/etc

多くのバージョン管理システムでは、ファイルのバージョンを数字または文字で識別し、バージョン番号、バージョン、リビジョン番号、リビジョン、またはリビジョンレベルと呼びます。例えば、ファイルの最初のバージョンはバージョン1です。ファイルが変更されると、次のバージョンはバージョン2になります。各バージョンには、タイムスタンプと変更を行ったユーザーが関連付けられています。リビジョンは比較、復元、および一部のファイルタイプではマージが可能です。^{[ 3 ]}

歴史

IBMのOS/360 IEBUPDTEソフトウェア更新ツールは1962年に登場し、バージョン管理システムツールの先駆けと言えるでしょう。IBM 360/370のインストールで頻繁に使用されていた2つのソース管理およびバージョン管理パッケージは、The LibrarianとPanvaletでした。^{[ 4 ] [ 5 ]}

ソースコード管理用に設計された完全なシステムは、1972年に開始されました。これは、やはりOS/360用のソースコード管理システム（SCCS）です。SCCSのユーザーマニュアル、特に1975年12月4日に発行された導入部は、これが最初の意図的なリビジョン管理システムであることを示唆していました。^{[ 6 ]}リビジョン管理システム（RCS）は1982年に続き^{[ 7 ]}、その後、並行バージョンシステム（CVS）がネットワークと並行開発機能をRCSに追加しました。CVSの後継として有力なのはSubversionであり、^{[ 8 ]} Gitなどの分散バージョン管理ツールが台頭しました。^{[ 9 ]}

構造

リビジョン管理は、データセットへの変更を時間の経過とともに管理します。これらの変更は、さまざまな方法で構造化できます

多くの場合、データはファイルやドキュメントなど、多数の個別のアイテムの集合体として考えられ、個々のファイルへの変更が追跡されます。これはファイルを個別に管理するという考え方と一致しますが、ファイル名の変更、分割、またはマージなどによってファイルIDが変更されると問題が発生します。そのため、Gitなどの一部のシステムでは、データ全体への変更を一括して扱うようにしています。これは単純な変更には直感的ではありませんが、複雑な変更は簡素化されます。

リビジョン管理下にあるデータがチェックアウトによって取得された後に変更された場合、通常はその変更はリビジョン管理システム（リポジトリ内）に直ちに反映されず、チェックインまたはコミットされる必要があります。リビジョン管理外のコピーは「作業コピー」と呼ばれます。簡単な例として、コンピュータファイルを編集する場合、編集プログラムによってメモリに保存されたデータが作業コピーであり、ファイルを保存するとコミットされます。具体的には、文書を印刷して手作業で編集し、後から変更内容をコンピュータに手動で入力して保存するといったことが考えられます。一方、ソースコード管理の場合、作業コピーは特定のリビジョンにあるすべてのファイルのコピーであり、通常は開発者のコ​​ンピュータにローカルに保存されます。^{[注 1 ]}この場合、ファイルの保存は作業コピーのみを変更し、リポジトリへのチェックインは別の手順となります。

複数の人が単一のデータセットまたはドキュメントで作業している場合、各自の作業コピー内に暗黙的にデータのブランチが作成されるため、後述するようにマージの問題が発生します。単純な共同ドキュメント編集では、ファイルロックを使用するか、他のユーザーが作業しているドキュメントで作業しないようにすることで、この問題を回避できます。

リビジョン管理システムは多くの場合、集中管理されており、単一の権威あるデータストアであるリポジトリが存在し、チェックアウトとチェックインはこの中央リポジトリを参照して行われます。一方、分散型リビジョン管理システムでは、権威ある単一のリポジトリは存在せず、データは任意のリポジトリにチェックアウトおよびチェックインできます。異なるリポジトリにチェックインする場合は、マージまたはパッチとして解釈されます。

グラフ構造

リビジョン管理されたプロジェクトの履歴グラフの例。幹は緑色、枝は黄色です。ただし、マージ（赤い矢印）があるため、グラフはツリーではありません

グラフ理論の観点から見ると、リビジョンは一般的に、幹から分岐する1本以上の平行な開発ライン（枝の「本線」）として視覚化される有向木（ツリー）を形成すると考えられています。実際には、この構造はより複雑で、有向非巡回グラフ（有向非巡回グラフ）を形成しますが、多くの用途においては「マージ付きツリー」で十分な近似値となります。

リビジョンは時間の経過とともに順番に発生するため、リビジョン番号またはタイムスタンプで順序付けることができます。^{[注 2 ]}リビジョンは過去のリビジョンに基づいていますが、「既存のテキストをすべて削除し、新しいテキストを挿入」など、以前のリビジョンを大幅にまたは完全に置き換えることができます。分岐や元に戻す操作がない最も単純なケースでは、各リビジョンは直前のリビジョンのみに基づいており、単一の最新バージョンである「HEAD」リビジョンまたはチップとともに単純な線を形成します。グラフ理論の用語で言えば、各リビジョンを点として描画し、各「派生リビジョン」の関係を矢印（通常は時間と同じ方向に古いものから新しいものを指す）として描画すると、これは線形グラフになります。分岐（複数の将来のリビジョンが過去のリビジョンに基づく）や、元に戻す（リビジョンが直前のリビジョンよりも古いリビジョンに依存する）がある場合、結果として得られるグラフは有向木（各ノードが複数の子を持つことができる）となり、子を持たないリビジョン（「各ブランチの最新リビジョン」）に対応する複数の先端を持つことになります。^{[注 3 ]}原則として、結果として得られるツリーには優先される先端（「メイン」の最新リビジョン）は必要ありません。さまざまな異なるリビジョンがあれば十分です。しかし、実際には、通常、1つの先端がHEADとして識別されます。新しいリビジョンがHEADに基づく場合、それは新しいHEADとして識別されるか、新しいブランチとみなされます。^{[注 4 ]}開始からHEADまでのリビジョンのリスト（グラフ理論用語では、前述のように線形グラフを形成するツリー内の唯一のパス）は、幹またはメインラインと呼ばれます。^{[注 5 ]}逆に、あるリビジョンが複数の以前のリビジョンに基づいている場合（ノードが複数の親を持つ場合）、結果として生じるプロセスはマージと呼ばれ、リビジョン管理における最も複雑な側面の一つです。これは、複数のブランチ（通常は2つですが、それ以上の場合もあります）で変更が発生し、それらの変更を組み込んだ単一のブランチにマージする場合に最もよく発生します。これらの変更が重複している場合、マージが困難または不可能になる可能性があり、手動による介入や書き換えが必要になります。

マージが存在する場合、ノードは複数の親を持つことができるため、結果として得られるグラフはもはやツリーではなく、ルート付き有向非巡回グラフ(DAG) になります。親は常に時間的に後ろ向きであるためグラフは非巡回であり、最も古いバージョンが存在するためルート付きです。トランクが存在すると仮定すると、ブランチからのマージはツリーの「外部」と見なすことができます。ブランチの変更はパッチとしてパッケージ化され、トランクの HEAD に適用され、ブランチへの明示的な参照なしに新しいリビジョンが作成され、ツリー構造が保持されます。したがって、バージョン間の実際の関係は DAG を形成しますが、これはツリーとマージを組み合わせたものと考えることができ、トランク自体は線です。

分散リビジョン管理では、複数のリポジトリが存在する場合、それらは単一のオリジナルバージョン（ツリーのルート）に基づいている場合がありますが、オリジナルのルートは必ずしも存在する必要はありません。代わりに、各リポジトリに個別のルート（最古のリビジョン）が存在する場合があります。これは、例えば、2人が別々にプロジェクトに取り組み始める場合などに発生します。同様に、複数のデータセット（複数のプロジェクト）が存在し、それらがデータを交換またはマージする場合、単一のルートは存在しません。ただし、単純化のために、1つのプロジェクトをプライマリプロジェクト、もう1つをセカンダリプロジェクトとして考えることができます。セカンダリプロジェクトは、独自のリビジョン履歴の有無にかかわらず、最初のプロジェクトにマージされます。

専門的な戦略

エンジニアリングの改訂管理は、初期の設計図またはブルーラインの改訂を追跡することに基づく形式化されたプロセスから発展しました。この管理システムは、設計の開発中にエンジニアリングの行き詰まりに達した場合に、設計の以前の状態に戻ることを暗黙的に可能にしました。変更を追跡するために改訂表が使用されました。さらに、図面の変更された領域は改訂雲マークを使用して強調表示されました

ビジネスと法律

バージョン管理はビジネスと法律の分野で広く普及しています。実際、「契約書のレッドライン」や「法務上のブラックライン」は、最も初期のバージョン管理の形態の一つであり^{[ 10 ]} 、現在でもビジネスと法律の分野で様々なレベルの洗練度で利用されています。最も高度な技術は、 CADファイルの変更を電子的に追跡するために使用され始めており（製品データ管理を参照）、従来のバージョン管理の「手動」による電子的な実装に取って代わっています。

ゲーム開発において

ゲーム開発では、多くの場合、大きなバイナリファイルと、異なる分野のチームが共同作業を行います。そのため、ゲームスタジオでは、大きなバイナリファイル、ファイルロック、高速同期を適切にサポートするバージョン管理システムを使用しています。一般的なツールには、Perforceやいくつかの新しいクラウドベースのシステムなどがあります。^{[ 11 ] [ 12 ]}

ソース管理モデル

従来のリビジョン管理システムは、すべてのリビジョン管理機能が共有サーバー上で実行される集中型モデルを採用しています。2人の開発者が同時に同じファイルを変更しようとすると、アクセス管理手段がなければ、互いの作業を上書きしてしまう可能性があります。集中型リビジョン管理システムは、ファイルロックとバージョンマージという2つの異なる「ソース管理モデル」のいずれかでこの問題を解決します。

アトミック操作

操作が中断されてもシステムが一貫した状態を維持される場合、その操作はアトミックです。この意味で、コミット操作は通常最も重要です。コミットは、リビジョン管理システムに一連の変更を最終的なものにし、すべてのユーザーが利用できるように指示します。すべてのリビジョン管理システムがアトミックコミットを備えているわけではありません。Concurrent Versions Systemにはこの機能がありません。^{[ 13 ]}

ファイルロック

「同時アクセス」の問題を防ぐ最も簡単な方法は、ファイルをロックして、一度に1人の開発者だけが中央の「リポジトリ」にあるファイルのコピーに書き込みアクセスできるようにすることです。1人の開発者がファイルを「チェックアウト」すると、他の開発者はそのファイルを読み取ることができますが、その開発者が更新されたバージョンを「チェックイン」する（またはチェックアウトをキャンセルする）まで、他の誰もそのファイルを変更することはできません

ファイルロックにはメリットとデメリットの両方があります。ユーザーが大規模なファイル（またはファイルグループ）の多くのセクションに大幅な変更を加える際に、困難なマージ競合をある程度防ぐことができます。ファイルが排他的にロックされた状態が長時間続くと、他の開発者がリビジョン管理ソフトウェアを介さずにローカルでファイルを変更してしまう可能性があり、他の変更が最終的にチェックインされた際に、困難な手動マージを余儀なくされる可能性があります。大規模な組織では、開発者がプロ​​ジェクト間を移動する間、ファイルが「チェックアウト」されたままロックされ、忘れ去られることがあります。これらのツールでは、誰がファイルをチェックアウトしたかを簡単に確認できる場合とできない場合があります。

バージョンのマージ

ほとんどのバージョン管理システムでは、複数の開発者が同じファイルを同時に編集できます。中央リポジトリに変更を「チェックイン」した最初の開発者が常に成功します。システムによっては、中央リポジトリにさらなる変更をマージし、他の開発者がチェックインした際に最初の開発者による変更を保持する 機能を備えている場合があります

2つのファイルのマージは非常に繊細な操作であり、通常はテキストファイルのようにデータ構造が単純な場合にのみ可能です。2つの画像ファイルをマージしても、画像ファイルが生成されない可能性があります。ファイルをチェックインする2番目の開発者は、マージ時に変更の互換性を確保し、マージ操作によってファイルに独自の論理エラーが発生しないように注意する必要があります。これらの問題により、ファイルタイプ 専用のマージプラグインがない限り、自動または半自動のマージ操作は主に単純なテキストベースのドキュメントでのみ利用できます。

予約編集の概念は、マージ機能が存在する場合でも、排他的書き込みアクセスのためにファイルを明示的にロックするオプションの手段を提供できます。

ベースライン、ラベル、タグ

ほとんどのリビジョン管理ツールでは、スナップショットを識別するアクション（「プロジェクトにラベルを付ける」）またはスナップショットの記録（「ベースラインXで試してみる」）を指す際に、これらの類似した用語（ベースライン、ラベル、タグ）のいずれか1つだけを使用します。通常、ドキュメントや議論では、ベースライン、ラベル、タグのいずれか1つだけが使用され、これらは同義語とみなすことができます。

ほとんどのプロジェクトでは、公開されたリリース、ブランチ、マイルストーンを示すために使用されるスナップショットなど、一部のスナップショットは他のスナップショットよりも重要です。

ベースラインという用語と、ラベルまたはタグのいずれかが同じコンテキストで一緒に使用される場合、ラベルとタグは通常、スナップショットの記録を識別または作成するツール内のメカニズムを指し、ベースラインは特定のラベルまたはタグの重要性の増加を示します。

構成管理に関する正式な議論のほとんどでは、ベースラインという用語が使用されます。

分散型リビジョン管理

分散型リビジョン管理システム（DRCS）は、集中型システムのクライアントサーバー型アプローチとは対照的に、ピアツーピア型アプローチを採用しています。クライアントが同期する単一の中央リポジトリではなく、各ピアのコードベースの作業コピーが真のリポジトリです。^{[ 14 ]}分散型リビジョン管理は、ピアツーピア間でパッチ（変更セット） を交換することで同期を行います。これにより、集中型システムとはいくつかの重要な違いがあります

• デフォルトでは、コードベースの正規の参照コピーは存在せず、作業コピーのみが存在します。
• 中央サーバーと通信する必要がないため、一般的な操作（コミット、履歴の表示、変更の元に戻すなど）は高速です。^{[ 1 ]：7}

むしろ、通信は、他のピアに変更をプッシュまたはプルする場合にのみ必要です。

• 各作業コピーはコードベースとその変更履歴のリモートバックアップとして効果的に機能し、データ損失に対する本質的な保護を提供します。^{[ 1 ]：4}

ベストプラクティス

バージョン管理のメリットを最大限に活用するには、ベストプラクティスに従うことが必要です。ベストプラクティスは、バージョン管理ツールやバージョン管理が適用される分野によって異なる場合があります。ソフトウェア開発において一般的に受け入れられているベストプラクティスには、小さな変更や増分的な変更を行うこと、 1つのタスクまたは修正のみを含むコミットを行うこと（当然の帰結として、動作するコードのみをコミットし、既存の機能を故意に壊さないこと）、リリース前に機能を完成させるためにブランチを使用すること、明確で説明的なコミットメッセージを書くこと、コミットの説明またはコードのいずれかで、何を、なぜ、どのように行うかを明確にすること、一貫したブランチ戦略を使用することなどがあります。^{[ 15 ]}コードレビューや自動回帰テストなどの他のソフトウェア開発のベストプラクティスは、バージョン管理のベストプラクティスの遵守に役立つ場合があります

コストとメリット

コストとメリットは、選択したバージョン管理ツールとそれが適用される分野によって異なります。このセクションでは、バージョン管理が広く適用されているソフトウェア開発分野について説明します

コスト

バージョン管理ソフトウェアのライセンス費用に加えて、バージョン管理の使用には時間と労力がかかります。バージョン管理の基礎となる概念を理解し、選択したバージョン管理ソフトウェアの操作に必要な技術的な詳細を習得する必要があります。バージョン管理のベストプラクティスを習得し、組織の既存のソフトウェア開発プラクティスに統合する必要があります。有益な利益を得るためにベストプラクティスに従うために必要な規律を維持するために、管理上の努力が必要になる場合があります

メリット

変更を元に戻すことが可能

主なメリットは、履歴を保持し、変更を元に戻せることです。これにより、開発者は簡単に変更を元に戻すことができます。これにより、開発者はより多くの実験の機会を得ることができ、既存のコードを壊してしまうという不安がなくなります。^{[ 16 ]}

ブランチは導入、保守、開発を簡素化します

ブランチは、デプロイメントとリリース管理を支援します。ブランチとマージ、ソースコードパッチの作成、パッケージ化、ラベル付け、そしてコードベースへのパッチの容易な適用は、開発、テスト、ステージング、本番環境など、デプロイメントプロセスの様々な段階に関連する複数のコードベースの保守と同時開発を簡素化します。^{[ 17 ]}

被害軽減、説明責任、プロセスと設計の改善

バージョン管理によって記録が保持され、誰が何をいつ、なぜ、どのように行ったかが追跡されるため、損害の軽減、説明責任の明確化、プロセスと設計の改善など、さまざまな利点が得られます。^{[ 18 ]}

バグが発生した場合、いつ何が行われたかを知っておくと、どのような問題が存在するか、どれくらいの期間存在していたか、問題の範囲と解決策を決定するのに役立ち、被害の軽減と復旧に役立ちます。^{[ 19 ]}以前のバージョンをインストールしてテストし、コードとコミットメッセージの検査によって得られた結論を検証することができます。^{[ 20 ]}

デバッグを簡素化

バージョン管理はデバッグを大幅に簡素化します。テストケースを複数のバージョンに適用することで、バグを引き起こした変更を迅速に特定できます。^{[ 21 ]} 開発者はコードベース全体に精通している必要はなく、問題を引き起こしたコードに集中できます

コラボレーションとコミュニケーションの改善

バージョン管理は、様々な方法でコラボレーションを強化します。バージョン管理は、競合する変更、つまり同じコード行に行われた互換性のない変更を特定できるため、開発者間の調整の必要性が軽減されます。^{[ 22 ]}

コミット、ブランチ、および関連するコミットメッセージとバージョンラベルをすべてパッケージ化することで、開発者間のコミュニケーションがその瞬間的にも長期的にも改善されます。^{[ 23 ]} 即時か遅延かにかかわらず、より良いコミュニケーションは、コードレビュープロセス、テストプロセス、およびソフトウェア開発プロセスのその他の重要な側面を改善することができます。

統合

より高度なリビジョン管理ツールの中には、他の多くの機能を備えており、他のツールやソフトウェアエンジニアリングプロセスとのより深い統合を可能にするものもあります

統合開発環境

Oracle JDeveloper、IntelliJ IDEA、Eclipse、Visual Studio、Delphi、NetBeans IDE、Xcode、GNU Emacs （vc.el経由）などのIDEでは、プラグインが利用できる場合が多い。高度な研究用プロトタイプでは、適切なコミットメッセージが生成されます。^{[ 24 ]}

一般的な用語

用語はシステムによって異なりますが、一般的に使用される用語には以下のものがあります。^{[ 25 ]}

ベースライン

文書またはソースファイルの承認済みのリビジョン。後続の変更が可能です。ベースライン、ラベル、タグを参照 してください

非難

特定の行を最後に変更した作成者とリビジョンを検索します

ブランチ

バージョン管理下にある一連のファイルは、ある時点でブランチまたはフォークされる可能性があり、その時点以降、それらのファイルの2つのコピーが互いに独立して異なる速度または異なる方法で開発される可能性があります

変更

変更（または差分、デルタ）は、バージョン管理下にある文書に対する特定の変更を表します。変更と見なされる変更の粒度は、バージョン管理システムによって異なります

変更リスト

多くのバージョン管理システムでは、アトミックな複数変更コミットにおいて、変更リスト（CL）、変更セット、更新、またはパッチは、単一のコミットで行われた変更のセットを識別します。これはソースコードの連続的なビューを表すこともでき、特定の変更リストIDの時点でのソースを調べることができます

チェックアウト

チェックアウト（またはco ）とは、リポジトリからローカルの作業コピーを作成することです。ユーザーは特定のリビジョンを指定したり、最新のものを取得したりできます。「チェックアウト」という用語は、作業コピーを表す名詞としても使用できます。ファイルが共有ファイルサーバーからチェックアウトされると、他のユーザーは編集できなくなります。ホテルのようなものだと考えてください。チェックアウトすると、ホテルのアメニティは利用できなくなります

クローン

クローンとは、別のリポジトリのリビジョンを含むリポジトリを作成することを意味します。これは、空の（新しく初期化された）リポジトリにプッシュまたはプルすることと同じです。名詞として、2つのリポジトリが同期され、同じリビジョンを含む場合、それらは クローンであると言えます

コミット（名詞）

バージョン管理ソフトウェアにおいて、チェンジセット（コミット^{[ 26 ]}、リビジョン^{[ 27 ] [ 28 ]}とも呼ばれる）とは、変更内容とそのメタ情報をまとめたものです。チェンジセットは、バージョン管理システムの変更リポジトリ内の2つの連続するバージョン間の正確な差分を記述します。バージョン管理システムでは、チェンジセットは通常、不可分な集合として扱われます。これは同期モデルの一つです。^{[ 29 ] [ 30 ]}

コミット（動詞）

コミット（チェックイン、CI、またはまれにインストール、送信、記録）とは、作業コピーに加えられた変更をリポジトリに書き込む、またはマージすることです。コミットにはメタデータ（通常は作成者情報と変更内容を説明するコミットメッセージ）が含まれます

コミットメッセージ

開発者が作成し、コミットと共に保存される、コミットを説明する短いメモです。理想的には、変更が行われた理由、変更の効果または目的の説明、変更がどのように機能するかについての明白でない側面を記録します

競合

競合は、異なる関係者が同じ文書に変更を加えた際に、システムがそれらの変更を調整できない場合に発生します。ユーザーは、変更を結合するか、一方の変更をもう一方の変更に優先させることで、競合を 解決する必要があります

デルタ圧縮

ほとんどのリビジョン管理ソフトウェアはデルタ圧縮を使用しています。これは、ファイルの連続バージョン間の差分のみを保持します。これにより、多くの異なるバージョンのファイルをより効率的に保存できます

動的ストリーム

一部またはすべてのファイルバージョンが親ストリームのバージョンのミラーであるストリーム

エクスポート

エクスポートとは、リポジトリからファイルを取得する行為です。チェックアウトと似ていますが、作業コピーで使用されるバージョン管理メタデータを含まないクリーンなディレクトリツリーを作成する点が異なります。これは、例えばコンテンツを公開する前によく使用されます

フェッチ

プルを参照してください。

前方統合

メイントランクで行われた変更を開発 (機能またはチーム) ブランチに マージするプロセス。

ヘッド

チップとも呼ばれ、トランクまたはブランチへの最新のコミットを指します。トランクと各ブランチにはそれぞれヘッドがありますが、HEADはトランクを指すために広く使用されることもあります。^{[ 31 ]}

輸入

インポートとは、ローカル ディレクトリ ツリー (現在作業コピーではないもの) をリポジトリに初めてコピーする行為です。

初期化

新しい空のリポジトリを作成します。

インターリーブデルタ

一部のリビジョン管理ソフトウェアでは、インターリーブ デルタが使用されます。これは、デルタ圧縮を使用するよりも効率的にテキスト ベースのファイルの履歴を保存できる方法です。

ラベル

タグを参照してください。

ロック

開発者がファイルをロックすると、ロックが解除されるまで他の誰もそのファイルを更新できません。ロックは、バージョン管理システム、または開発者間の非公式なコミュニケーション（ソーシャルロックとも呼ばれます） によってサポートされます

幹線

幹線に似ていますが、枝ごとに幹線が存在します

マージ

マージまたは統合とは、2つの変更セットを1つのファイルまたはファイルセットに適用する操作です。いくつかのサンプルシナリオを以下に示します

• ユーザーは、一連のファイルに対して作業を行い、他のユーザーがリポジトリにチェックインした変更を作業コピーに反映または同期します。 ^{[ 32 ]}
• ユーザーが、ファイルがチェックアウトされてから他のユーザーによって更新されたファイルをチェックインしようとすると、リビジョン管理ソフトウェアは自動的にファイルをマージします (通常は、自動マージを続行するかどうかをユーザーに確認した後、場合によっては、マージが明確かつ合理的に解決できる場合にのみ自動マージを実行します)。
• ブランチが作成され、ファイル内のコードが個別に編集され、更新されたブランチは後で単一の統合されたトランクに組み込まれます。
• 一連のファイルが分岐され、分岐前に存在していた問題が一方のブランチで修正され、その修正がもう一方のブランチにマージされます。（このタイプの選択的マージは、前述の完全マージと区別するためにチェリーピックと呼ばれることもあります。）

促進する

管理の緩い場所から管理の厳しい場所にファイルの内容をコピーする行為。例えば、ユーザーのワークスペースからリポジトリへ、またはストリームからその親へ。^{[ 33 ]}

プル、プッシュ

あるリポジトリから別のリポジトリにリビジョンをコピーします。プルは受信側のリポジトリによって開始され、プッシュはソース側によって開始されます。フェッチはプルの同義語として、またはプルに続いて更新が行われることを意味するために使用されることが あります

プルリクエスト

分散型バージョン管理システムを使用するソースコードリポジトリへの貢献は、通常、プルリクエスト（マージリクエストとも呼ばれる）によって行われます。^{[ 34 ]}貢献者は、プロジェクトのメンテナーにソースコードの変更をプルするよう要求するため、「プルリクエスト」と呼ばれます。貢献をソースベースの一部とするには、メンテナーはプルリクエストをマージする必要があります。 ^{[ 35 ]}

開発者はプルリクエストを作成して、メンテナーに新しい変更を通知します。各プルリクエストにはコメントスレッドが関連付けられます。これにより、コード変更に関する集中的な議論が可能になります。送信されたプルリクエストは、リポジトリにアクセスできるすべてのユーザーに表示されます。プルリクエストはメンテナーによって承認または拒否されます。^{[ 36 ]}

プルリクエストがレビューされ承認されると、リポジトリにマージされます。確立されたワークフローによっては、正式リリースに含める前にコードをテストする必要がある場合があります。そのため、一部のプロジェクトでは、テストされていないプルリクエストをマージするための特別なブランチが用意されています。^{[ 35 ] [ 37 ]}他のプロジェクトでは、継続的インテグレーションツールを使用して、すべてのプルリクエストに対して自動テストスイートを実行し、レビュー担当者が新しいコードに適切なテストカバレッジが含まれているかどうかを確認します。

リポジトリ

バージョン管理システムにおいて、リポジトリとは、一連のファイルまたはディレクトリ構造のメタデータを格納するデータ構造です。^{[ 38 ]}使用しているバージョン管理システムがGitやMercurialのような分散型か、Subversion、CVS、Perforceのような集中型かによって、リポジトリ内の情報全体がすべてのユーザーのシステムに複製されるか、単一のサーバーで管理されるかが異なります。^{[ 39 ]}リポジトリに含まれるメタデータには、リポジトリ内の変更の履歴記録、コミットオブジェクトのセット、およびヘッドと呼ばれるコミットオブジェクトへの参照のセットなどが含まれます

解決

同じ文書に対する異なる変更間の競合に対処するためのユーザー介入行為

逆統合

異なるチームのブランチをバージョン管理システムのメイントランクにマージするプロセス

リビジョンと

バージョンとは、形式上の変更のことです。SVKでは、リビジョンとは、リポジトリ内のツリー全体の、ある時点での状態を指します

共有

1つのファイルまたはフォルダを複数のブランチで同時に利用できるようにする操作。あるブランチで共有ファイルが変更されると、他のブランチでも変更されます。

ストリーム

他のコンテナとの関係が既知の、分岐したファイルのためのコンテナ。ストリームは階層構造を形成し、各ストリームは親ストリームからさまざまなプロパティ（バージョン、名前空間、ワークフロールール、サブスクライバーなど）を継承できます

タグ

タグまたはラベルは、多くのファイルにわたって一貫した、ある時点における重要なスナップショットを指します。その時点で、これらのファイルはすべて、ユーザーフレンドリーで意味のある名前またはリビジョン番号でタグ付けされている場合があります。ベース ライン、ラベル、タグを参照してください

トランク

トランクとは、ブランチではない独自の開発ラインです（ベースライン、メインライン、マスターとも呼ばれます^{[ 40 ] [ 41 ]}）。

更新

更新（または同期、ただし同期はプッシュとプルを組み合わせた意味を持つこともあります）は、リポジトリ内で行われた変更（たとえば他の人による）をローカルの作業コピーにマージします。 更新は、一部のCMツール（CM+、PLS、SMS）で変更パッケージの概念（チェンジリストを参照）を表すために使用される用語でもあります。各リポジトリに正確に1つの作業コピーを持つことを要求するリビジョン管理システム（分散システムで一般的）における チェックアウトと同義です

ロック解除

ロックを解除する

作業コピー

作業コピーとは、リポジトリの特定の時刻またはリビジョンにおけるファイルのローカルコピーです。リポジトリ内のファイルに対するすべての作業は、最初に作業コピーで行われるため、この名前が付けられています。概念的には、サンドボックスです

参照

• 変更管理
• 変更履歴
• ブロックチェーン
• バージョン管理ソフトウェアの比較
• ソースコードホスティング施設の比較
• データバージョン管理
• 分散バージョン管理
• バージョン管理ソフトウェアの一覧
• ノンリニア編集
• ソフトウェア構成管理
• ソフトウェアのバージョン管理
• バージョン管理ファイルシステム

注記

1. この場合、編集バッファは作業コピーの二次的な形式であり、そのようには呼ばれません
2. 原則として、2つのリビジョンは同じタイムスタンプを持つ場合があり、そのため行内で順序付けすることはできません。これは通常、別々のリポジトリの場合に当てはまりますが、単一のリポジトリ内の複数のブランチへの同時変更の場合にも当てはまります。このような場合、リビジョンはリポジトリまたはブランチ（またはリポジトリ内のブランチ）ごとに1行ずつ、別々の行の集合として考えることができます。
3. リビジョンまたはリポジトリの「ツリー」を、作業コピー内のファイルのディレクトリ ツリーと混同しないでください。
4. 新しいブランチが HEAD に基づいている場合、子が存在するため、トポロジ的には HEAD は先端ではなくなります。
5. 「メインライン」は、別のブランチ内のメインパスを指す場合もあります。

参考文献

1. オサリバン、ブライアン (2009). Mercurial: the Definitive Guide . セバストーポル: O'Reilly Media, Inc. ISBN 978-0-596-55547-4 2019年12月8日時点のオリジナルよりアーカイブ。2015年9月4日閲覧
2. 「Google Docs」、ファイルの変更内容を確認する、Google Inc.、2022年10月6日時点のオリジナルよりアーカイブ、 2021年4月21日閲覧。
3. スコット、チャコン、ストラウブ、ベン (2014). Pro Git 第2版. 米国: Apress . p. 14. 2015年12月25日時点のオリジナルよりアーカイブ。2022年2月19日閲覧
4. Goetz, Martin (2002年5月3日). 「マーティン・ゲッツへのインタビュー」（インタビュー）. ジェフリー・R・ヨストによるインタビュー. ワシントンD.C.: ミネソタ大学チャールズ・バベッジ研究所. pp.  5– 7. 2024年9月26日時点のオリジナルよりアーカイブ。2023年8月17日閲覧。
5. Piscipo, Joseph (2002年5月3日). "An Interview with Joseph Piscopo" (インタビュー). インタビュー：トーマス・ヘイグ. ワシントンD.C.: Charles Babbage Institute, University of Minnesota. pp. 3, 5, 12– 13. 2024年9月26日時点のオリジナルよりアーカイブ。2023年8月17日閲覧。
6. Rochkind, Marc J. (1975). 「ソースコード管理システム」（PDF） . IEEE Transactions on Software Engineering . SE-1 (4): 364– 370. Bibcode : 1975ITSEn...1..364R . doi : 10.1109/TSE.1975.6312866 . S2CID 10006076. 2020年9月30日時点のオリジナル（PDF）からアーカイブ。 2020年9月3日閲覧。 
7. Tichy, Walter F. (1985). 「Rcs — バージョン管理システム」 .ソフトウェア: 実践と経験. 15 (7): 637– 654. doi : 10.1002/spe.4380150703 . ISSN 0038-0644 . S2CID 2605086. 2024年9月26日時点のオリジナルよりアーカイブ。2023年12月28日閲覧。  
8. Collins-Sussman, Ben; Fitzpatrick, BW; Pilato, CM (2004), Version Control with Subversion , O'Reilly, ISBN 0-596-00448-6
9. ジョン・ローリガー、マシュー・マカロー（2012年）『Gitによるバージョン管理：共同ソフトウェア開発のための強力なツールとテクニック』オライリーメディア、  2～ 5ページ。ISBN 978-1-4493-4504-4 2024年9月26日にオリジナルからアーカイブ。2023年3月22日閲覧
10. エンジニアリング図面については、ホワイトプリント#文書管理を参照してください。20 世紀に導入されていた手動システムの一部については、たとえばヒューズ エアクラフト社のエンジニアリング手順を参照してください。この手順の各改訂には、ローレンス A. ハイランドによる承認が必要でした。また、米国政府によって制定された承認手順も参照してください。
11. Zitzman, Sharone (2023年5月9日). 「ゲーム開発者が知っておくべき5つのバージョン管理ツール」 . The New Stack . 2025年11月29日閲覧。
12. 「Unreal Engineでのコラボレーションとバージョン管理 | Unreal Engine 5.7ドキュメント | Epic Developer Community」Epic Games Developer . 2025年11月29日閲覧。
13. Smart, John Ferguson (2008). Java Power Tools . O'Reilly Media, Inc.. p. 301. ISBN 978-1-4919-5454-6 2024年9月26日時点のオリジナルよりアーカイブ。2019年7月20日閲覧
14. Wheeler, David. 「オープンソースソフトウェア/フリーソフトウェア（OSS/FS）ソフトウェア構成管理（SCM）システムに関するコメント」 。 2020年11月9日時点のオリジナルよりアーカイブ。 2007年5月8日閲覧。
15. GitLab. 「Gitバージョン管理のベストプラクティスとは？」 . gitlab.com . 2022年11月11日閲覧。
16. Alessandro Picarelli (2020-11-17). 「バージョン管理を使用しないことのコスト」 . 2022-11-19にオリジナルからアーカイブ。2022-11-18に閲覧。工数で言えば、バージョン管理を使用した場合の6～48倍のコストがかかります。これは、1人の開発者が複数のモデルを巻き戻す作業です。
17. Irma Azarian (2023-06-14). 「ソフトウェアバージョン管理のレビュー：システム、利点、そしてなぜそれが重要なのか」。2024年9月26日時点のオリジナルからのアーカイブ。 2022年11月18日閲覧。バージョン管理システムを使用すると、コードをコミットする前に、ファイルを比較し、差異を特定し、必要に応じて変更をマージすることができます。また、バージョン管理は、現在開発中、品質保証中、本番環境にあるバージョンを識別できるため、アプリケーションのビルドを追跡する優れた方法でもあります。
18. ReQtest (2020-10-26). 「バージョン管理のメリットとは？」オリジナルから2022年11月22日にアーカイブ。2022年11月21日閲覧。ドキュメントの履歴は、作成者と編集日に関する貴重な情報を提供します。また、変更の目的も示します。これは、以前のバージョンで発生した問題の解決に役立つため、最新バージョンに取り組む開発者に影響を与えます。ドキュメントの作成者を特定できることで、現在のチームはドキュメントを特定の貢献者にリンクさせることができます。これにより、現在のチームはバグ修正に役立つパターンを発見することができ、ソフトウェア全体の機能向上に役立ちます。
19. Chiradeep BasuMallick (2022年10月6日). 「バージョン管理とは何か？ 意味、ツール、そして利点」 . 2022年11月19日時点のオリジナルよりアーカイブ。2022年11月18日閲覧。ソフトウェアチームは、コードレビューを通じて以前のバージョンを調査することで、ソリューションの進化を把握できます。
20. Chiradeep BasuMallick (2022年10月6日). 「バージョン管理とは何か？ 意味、ツール、そして利点」 . 2022年11月19日時点のオリジナル記事よりアーカイブ。 2022年11月18日閲覧。エラーが発生した場合、開発者は時間を遡ってコードの以前のイテレーションを確認し、チームメンバー全員への影響を最小限に抑えながらミスを修正することができます。
21. Chacon, Scott; Straub, Ben (2022-10-03). "Pro Git" (バージョン 2.1.395-2-g27002dd ed.). Apress. 2024年9月26日時点のオリジナルよりアーカイブ。2022年11月18日閲覧。git bisectツールは、自動バイナリサーチによって、バグや問題が最初に発生したコミットを特定するために使用できる、非常に便利なデバッグツールです。
22. Irma Azarian (2023-06-14). 「ソフトウェアバージョン管理のレビュー：システム、利点、そして重要性」。2024年9月26日時点のオリジナルよりアーカイブ。 2022年11月18日閲覧。バージョン管理は、特に複数の開発者が単一のアプリケーションに取り組んでいる場合、ファイル共有を容易にするため、非常に貴重なプロセスです。バージョン管理がなければ、開発者は最終的に互いの足を引っ張り合い、他の誰かが気付かないうちに完了したコード変更を上書きしてしまう可能性があります。これらのシステムを使用すると、ファイルをチェックアウトして変更内容を確認し、チェックイン時に他のユーザーによってファイルが変更されている場合は警告が表示され、マージできるようになります。
23. Jesse Phillips (2019-01-21) [2018-12-12]. 「Gitはコミュニケーションツールです」。2022年11月19日時点のオリジナルからのアーカイブ。 2022年11月18日閲覧。リベース、マージ、スカッシュの使用については議論が続いています。私は、これらすべての選択肢の核心であるコミュニケーションに焦点を当てたいと思います。
24. Cortes-Coy, Luis Fernando; Linares-Vasquez, Mario; Aponte, Jairo; Poshyvanyk, Denys (2014). 「ソースコードの変更の要約によるコミットメッセージの自動生成について」. 2014 IEEE 第14回国際ソースコード分析・操作ワーキングカンファレンス. IEEE. pp.  275– 284. doi : 10.1109/scam.2014.14 . ISBN 978-1-4799-6148-1. S2CID  360545 .
25. ウィンガード、ローラ (2005). 『Practical Perforce』 . O'Reilly. ISBN 0-596-10185-62007年12月21日にオリジナルからアーカイブ。2006年8月27日閲覧
26. gitglossaryの変更セット
27. gitglossaryのリビジョン
28. Mercurial を理解する - Mercurial
29. Mercurial: ChangeSet 2010年1月15日アーカイブ、 Wayback Machine
30. 「バージョン管理システムの比較」。Better SCM Initiative。 2009年3月21日時点のオリジナルよりアーカイブ。
31. Gregory, Gary (2011年2月3日). 「バージョン管理システムにおけるTrunkとHEAD」 . Java、Eclipse、その他の技術小ネタ. 2020年9月20日時点のオリジナルよりアーカイブ。 2012年12月16日閲覧。
32. Collins-Sussman、Fitzpatrick & Pilato 2004、1.5 : SVN ツアー サイクルの解決:「G は merGed の略で、これは、ファイルに最初はローカルの変更があったが、リポジトリからの変更がローカルの変更と重複しなかったことを意味します。」
33. コンセプトマニュアル（バージョン4.7版）。Accurev. 2008年7月。
34. シツェブランダイ、シツェ (2014 年 9 月 29 日)。「GitLab フロー」。GitLab 。2018 年8 月 4 日に取得。
35. Johnson, Mark (2013年11月8日). 「プルリクエストとは何か？」 Oaawatch . 2016年3月27日閲覧。
36. 「プルリクエストの使用」 . GitHub . 2016年3月27日閲覧。
37. 「プルリクエストの作成」。Atlassian 。 2016年3月27日閲覧。
38. "SVNBook" . 2012年4月20日閲覧。
39. 「バージョン管理の概念とベストプラクティス」 2018年3月3日。2020年4月27日時点のオリジナルよりアーカイブ。2020年7月10日閲覧。
40. Wallen, Jack (2020年9月22日). 「GitHub、10月からmasterをmainに置き換える：開発者が今すべきこと」 . TechRepublic . 2021年2月8日時点のオリジナルよりアーカイブ。 2022年4月24日閲覧。
41. Heinze, Carolyn (2020年11月24日). 「GitHubがmasterブランチをmainに変更した理由」 TheServerSide . 2022年5月26日時点のオリジナルよりアーカイブ。 2022年4月24日閲覧。

外部リンク

• 「バージョン管理ビジュアルガイド」、より分かりやすく解説。
• シンク、エリック、「ソース管理」、SCM（ハウツー）バージョン管理の基本。