バージョン管理

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

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

バージョン管理システムは、バージョン管理を自動化するソフトウェアツールです。また、バージョン管理は、ワードプロセッサスプレッドシート、共同Webドキュメント[2]コンテンツ管理システム(例:Wikipediaのページ履歴)などの一部のシステムの機能として組み込まれています。

バージョン管理には、古いバージョンの表示が含まれ、ファイルを以前のバージョンに 戻すことができます。

概要

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

最も単純なレベルでは、開発者はプログラムの異なるバージョンの複数のコピーを保持し、それらに適切なラベルを付けるだけです。この単純なアプローチは、多くの大規模ソフトウェア プロジェクトで使用されてきました。この方法は機能しますが、プログラムのほぼ同一のコピーを多数維持する必要があるため非効率的です。開発者側には多くの自己規律が求められ、ミスにつながることがよくあります。コード ベースは同じであるため、開発者グループに読み取り、書き込み、実行の権限を付与する必要があり、これにより、コード ベースが侵害されないように権限を管理する誰かのプレッシャーが加わり、複雑さが増します。その結果、リビジョン管理プロセスの一部またはすべてを自動化するシステムが開発されました。これにより、バージョン管理手順の管理の大部分が舞台裏で隠されます。

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

リビジョン管理では、 Unix システム内またはUnixシステム上に通常保存される構成ファイルの変更も追跡できます。これにより、システム管理者は、変更内容を簡単に追跡し、必要に応じて以前のバージョンにロールバックする別の方法を得ることができます。 /etc/usr/local/etc

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

歴史

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

ソースコード管理用に設計された完全なシステムは、1972年に同じシステム(OS/360)用のソースコード管理システムとして開始されました。ソースコード管理システムの導入は1975年12月4日に公開され、歴史的にはこれが最初の意図的なリビジョン管理システムであることを示唆していました。 [6] RCSはその後すぐに続き、[7]そのネットワークバージョンであるConcurrent Versions Systemが登場しました。Concurrent Versions Systemの次の世代はSubversionが主流となり、[8] Gitなどの分散リビジョン管理ツールが続きました[9]

構造

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

多くの場合、データはファイルやドキュメントなどの多くの個別のアイテムのコレクションとして考えられ、個々のファイルへの変更が追跡されます。これは個別のファイルに関する直感と一致しますが、ファイルの名前変更、分割、またはマージ中など、アイデンティティが変更される場合に問題が発生します。したがって、Gitなどの一部のシステムでは、代わりにデータ全体への変更を考慮します。これは単純な変更に対しては直感的ではありませんが、より複雑な変更を簡素化します。

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

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

リビジョン コントロール システムは、多くの場合、集中管理されており、単一の信頼できるデータ ストアであるリポジトリがあり、チェックアウトとチェックインはこの中央リポジトリを参照して行われます。一方、分散リビジョン コントロールでは、信頼できる単一のリポジトリはなく、データはどのリポジトリでもチェックアウトおよびチェックインできます。別のリポジトリにチェックインすると、マージまたはパッチとして解釈されます。

グラフ構造

リビジョン管理されたプロジェクトの履歴グラフの例。トランクは緑色、ブランチは黄色で、マージ (赤い矢印) が存在するためグラフはツリーではありません。

グラフ理論の観点では、リビジョンは一般に、開発ライン () とそこから分岐して有向ツリーを形成するものと考えられており、これは幹から分岐する 1 つ以上の並行開発ライン (枝の「主線」) として視覚化されます。実際には構造はより複雑で、有向非巡回グラフを形成しますが、多くの目的において「マージのあるツリー」は適切な近似値です。

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

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

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

専門的な戦略

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

ビジネスと法律

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

ソース管理モデル

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

アトミック操作

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

ファイルロック

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

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

バージョンのマージ

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

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

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

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

ほとんどのリビジョン管理ツールでは、スナップショットを識別するアクション (「プロジェクトにラベルを付ける」) またはスナップショットの記録 (「ベースラインXで試す」) を参照するために、これらの類似の用語 (ベースライン、ラベル、タグ) のいずれか 1 つだけを使用します。通常、ドキュメントやディスカッションでは、ベースラインラベルタグのいずれか 1 つの用語だけが使用され[引用が必要]ます。これらは同義語と見なすことができます。

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

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

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

分散リビジョン管理

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

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

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

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

ベストプラクティス

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

コストとメリット

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

費用

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

利点

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

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

ブランチ化により、導入、保守、開発が簡素化されます

ブランチはデプロイメントに役立ちます。ブランチとマージ、ソースコードパッチの作成、パッケージ化、ラベル付け、コードベースへのパッチの簡単な適用により、開発、テスト、ステージング、本番環境など、デプロイメントプロセスのさまざまな段階に関連する複数のコードベースのメンテナンスと同時開発が簡素化されます。[15]

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

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

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

デバッグを簡素化

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

コラボレーションとコミュニケーションの向上

バージョン管理はさまざまな方法でコラボレーションを強化します。バージョン管理では競合する変更、つまり同じコード行に行われた互換性のない変更を識別できるため、開発者間の調整の必要性が低くなります。[20]

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

統合

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

統合開発環境

Oracle JDeveloperIntelliJ IDEAEclipseVisual StudioDelphiNetBeans IDEXcodeGNU Emacs (vc.el経由)などのIDE用のプラグインが利用できる場合が多い。高度な研究プロトタイプは適切なコミットメッセージを生成する。[22]

一般的な用語

用語はシステムによって異なる場合がありますが、一般的に使用されている用語には次のようなものがあります。[23]

ベースライン

ドキュメントまたはソース ファイルの承認済みリビジョン。これに対して後続の変更を加えることができます。ベースライン、ラベル、タグを参照してください。

非難

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

支店

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

変化

変更(またはdiffdelta )は、バージョン管理下にあるドキュメントに対する特定の変更を表します。変更と見なされる変更の粒度は、バージョン管理システムによって異なります。

変更リスト

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

チェックアウト

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

クローン

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

コミット(名詞)

バージョン管理ソフトウェアでは、変更セット(コミット[24]やリビジョン[25] [26]とも呼ばれる)は、変更に関するメタ情報とともにパッケージ化された一連の変更です。変更セットは、バージョン管理システムの変更リポジトリ内の2つの連続するバージョン間の正確な違いを記述します。変更セットは通常、バージョン管理システムによって不可分なセットである原子単位として扱われます。これが同期モデルの1つです。[27] [28]

コミットする(動詞)

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

コミットメッセージ

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

対立

競合は、異なる関係者が同じドキュメントに変更を加えたときに発生し、システムが変更を調整できません。ユーザーは、変更を組み合わせるか、1 つの変更を他の変更よりも優先して選択することで、競合を 解決する必要があります。

デルタ圧縮

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

ダイナミックストリーム

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

輸出

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

フェッチ

「プル」を参照してください

前方統合

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

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

輸入

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

初期化

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

インターリーブデルタ

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

ラベル

タグを参照してください

ロック

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

メインライン

trunkに似ていますが、ブランチごとにメインラインが存在する場合があります。

マージ

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

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

推進する

ファイルの内容を、管理の行き届いていない場所から管理の行き届いた場所にコピーする行為。たとえば、ユーザーのワークスペースからリポジトリへ、またはストリームからその親へコピーするなど。[31]

引く、押す

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

プルリクエスト

分散バージョン管理システムを使用するソースコードリポジトリへの貢献は、通常、プルリクエスト(マージリクエストとも呼ばれる)によって行われます。[32]貢献者は、プロジェクトのメンテナーにソースコードの変更をプルするように要求します。そのため、「プルリクエスト」という名前が付けられています。貢献がソースベースの一部になる場合は、メンテナーがプルリクエストをマージする必要があります。 [33]

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

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

リポジトリ

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

解決する

同じドキュメントに対する異なる変更間の競合に対処するためのユーザー介入行為。

逆統合

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

改訂とバージョン

バージョンとは、フォームの変更のことです。SVK では、リビジョンとは、リポジトリ内のツリー全体の特定の時点の状態のことです。

共有

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

ストリーム

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

鬼ごっこ

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

トランク

トランク、ブランチではない独自の開発ラインです(ベースライン、メインライン、マスターとも呼ばれる[38] [39]

アップデート

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

ロック解除

ロックを解除します。

作業コピー

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

参照

ノート

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

参考文献

  1. ^ abc オサリバン、ブライアン(2009)。Mercurial:決定版ガイド。セバストポル:O'Reilly Media、Inc。ISBN 978-0-596-55547-4. 2015年9月4日閲覧
  2. ^ Google ドキュメント」、ファイル内の変更内容を確認する、Google Inc.
  3. ^ Scott, Chacon; Straub, Ben (2014). Pro Git 第2版. 米国: Apress . p. 14.
  4. ^ Goetz, Martin (2002 年 5 月 3 日)。「Martin Goetz とのインタビュー」(インタビュー)。インタビュー: Jeffrey R. Yost。ワシントン DC: Charles Babbage Institute、ミネソタ大学。pp. 5–7。
  5. ^ ピシポ、ジョセフ (2002 年 5 月 3 日)。「ジョセフ・ピスコポへのインタビュー」(インタビュー)。トーマス・ヘイグによるインタビュー。ワシントン DC: ミネソタ大学チャールズ・バベッジ研究所。pp. 3、5、12–13。
  6. ^ Rochkind, Marc J. (1975). 「ソースコード管理システム」(PDF) . IEEE Transactions on Software Engineering . SE-1 (4): 364–370. doi :10.1109/TSE.1975.6312866. S2CID  10006076.
  7. ^ Tichy, Walter F. (1985). 「Rcs — バージョン管理システム」.ソフトウェア: 実践と経験. 15 (7): 637–654. doi :10.1002/spe.4380150703. ISSN  0038-0644. S2CID  2605086.
  8. ^ Collins-Sussman, Ben; Fitzpatrick, BW; Pilato, CM (2004)、『Subversion によるバージョン管理』、O'Reilly、ISBN 0-596-00448-6
  9. ^ Loeliger, Jon; McCullough, Matthew (2012). Git によるバージョン管理: 共同ソフトウェア開発のための強力なツールとテクニック。O'Reilly Media。pp. 2–5。ISBN 978-1-4493-4504-4
  10. ^ エンジニアリング図面については、ホワイトプリント#文書管理を参照してください。20世紀に導入された手動システムの一部については、たとえばヒューズ・エアクラフト社エンジニアリング手順書を参照してください。この手順書の各改訂には、ローレンス・A・ハイランドによる承認が必要でした。また、米国政府によって制定された承認手順も参照してください。
  11. ^ Smart, John Ferguson (2008)。Java Power Tools。「O'Reilly Media, Inc.」。p. 301。ISBN 978-1-4919-5454-6. 2019年7月20日閲覧
  12. ^ Wheeler, David. 「オープンソースソフトウェア/フリーソフトウェア(OSS/FS)ソフトウェア構成管理(SCM)システムに関するコメント」。2020年11月9日時点のオリジナルよりアーカイブ。 2007年5月8日閲覧
  13. ^ GitLab. 「Git バージョン管理のベストプラクティスとは?」. gitlab.com . 2022 年 11 月 11 日閲覧
  14. ^ Alessandro Picarelli ( 2020-11-17 ). 「バージョン管理を使用しない場合のコスト」。2022-11-18 に取得工数で言えば、バージョン管理を使用した場合の 6 ~ 48 倍のコストがかかります。これは、1 人の開発者がいくつかのモデルを巻き戻す場合のコストです。
  15. ^ Irma Azarian ( 2023-06-14 ). 「ソフトウェアバージョン管理のレビュー:システム、利点、そしてそれが重要な理由」。2022-11-18 に取得バージョン管理システムを使用すると、コードをコミットする前に、ファイルを比較し、違いを特定し、必要に応じて変更をマージできます。また、バージョン管理は、現在開発、QA、および本番環境にあるバージョンを識別できるため、アプリケーションのビルドを追跡するのに最適な方法です。
  16. ^ ReQtest (2020-10-26). 「バージョン管理の利点は何ですか?」2022-11-21に取得。ドキュメントの履歴は、作成者と編集日に関する貴重な情報を提供します。 また、変更の目的も示します。 以前のバージョンで発生した問題を解決するのに役立つため、最新バージョンで作業する開発者に影響を与えます。 ドキュメントの作成者を識別する機能により、現在のチームはドキュメントを特定の貢献者にリンクできます。 これにより、現在のチームはバグの修正に役立つパターンを発見できます。 これは、ソフトウェアの全体的な機能の向上に役立ちます。
  17. ^ Chiradeep BasuMallick (2022-10-06). 「バージョン管理とは何か? 意味、ツール、利点」2022-11-18に取得。ソフトウェア チームは、コード レビューを通じて以前のバージョンを調べることで、ソリューションの進化を把握できます。
  18. ^ Chiradeep BasuMallick (2022-10-06). 「バージョン管理とは? 意味、ツール、利点」2022-11-18に取得。エラーが発生した場合、開発者は時間をさかのぼってコードの以前の反復を確認し、チームメンバー全員への影響を最小限に抑えながら間違いを修正できます。
  19. ^ Chacon, Scott; Straub, Ben (2022-10-03). 「Pro Git」(バージョン 2.1.395-2-g27002dd ed.). Apress . 2022-11-18に取得。git bisect ツールは、自動バイナリ検索を実行して、バグや問題が最初に発生したコミットを見つけるために使用される、非常に便利なデバッグ ツールです。
  20. ^ Irma Azarian ( 2023-06-14 ). 「ソフトウェアバージョン管理のレビュー:システム、利点、およびそれが重要な理由」。2022-11-18 に取得バージョン管理は、特に複数の開発者が単一のアプリケーションに取り組んでいる場合は、ファイルを簡単に共有できるため、非常に貴重なプロセスです。バージョン管理がなければ、開発者は最終的にお互いの足を引っ張り、他の誰かが気付かないうちに完了したコード変更を上書きすることになります。これらのシステムを使用すると、ファイルをチェックアウトして変更することができ、チェックイン中にファイルが別のユーザーによって変更されている場合は、警告が表示され、ファイルをマージできます。
  21. ^ Jesse Phillips (2019-01-21) [ 2018-12-12 ]. 「Git はコミュニケーションツールです」。2022-11-18 取得リベース、マージ、スカッシュの使用については議論が続いています。私は、これらすべての選択肢の要点であるコミュニケーションに焦点を当てたいと思います。
  22. ^ 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  。
  23. ^ ウィンガード、ローラ (2005)。実践的パーフォース。オライリー。ISBN 0-596-10185-6. 2007年12月21日時点のオリジナルよりアーカイブ。 2006年8月27日閲覧
  24. ^ gitglossaryの変更セット
  25. ^ gitglossary のリビジョン
  26. ^ Mercurial を理解する - Mercurial
  27. ^ Mercurial: ChangeSet 2010年1月15日アーカイブ、Wayback Machine
  28. ^ 「バージョン管理システムの比較」。Better SCM Initiative。2009 年 3 月 21 日時点のオリジナルよりアーカイブ。
  29. ^ Gregory, Gary (2011 年 2 月 3 日)。「バージョン コントロール システムにおける Trunk と HEAD」。Java 、Eclipse、その他の技術情報。2012年 12 月 16 日閲覧
  30. ^ Collins-Sussman、Fitzpatrick、Pilato 2004、1.5: SVN ツアー サイクルの解決: 「G は merGed の略で、これは、ファイルにはもともとローカルの変更があったが、リポジトリからの変更がローカルの変更と重複しなかったことを意味します。」
  31. ^ コンセプトマニュアル(バージョン4.7版)。Accurev。2008年7月。
  32. ^ Sijbrandij、Sytse(2014年9月29日)。 「GitLab Flow」。2018年8月4日閲覧
  33. ^ ab Johnson, Mark (2013 年 11 月 8 日)。「プルリクエストとは何か?」Oaawatch。20163 月 27 日閲覧
  34. ^ 「プルリクエストの使用」。GitHub 。 2016年3月27日閲覧
  35. ^ 「プルリクエストの作成」。Atlassian 2016年3月27日閲覧。
  36. ^ 「SVNBook」 。 2012年4月20日閲覧
  37. ^ 「バージョン管理の概念とベストプラクティス」 2018-03-03。2020-04-27時点のオリジナルよりアーカイブ。2020-07-10に閲覧
  38. ^ Wallen, Jack (2020-09-22). 「GitHub、10月からマスターをメインに置き換える: 開発者が今すべきこと」TechRepublic . 2022年4月24日閲覧
  39. ^ Heinze, Carolyn (2020-11-24). 「GitHub がマスター ブランチの名前を main に変更した理由」TheServerSide . 2022-04-24閲覧

外部リンク

  • 「バージョン管理のビジュアルガイド」、よりわかりやすく説明
  • Sink、Eric、「ソース コントロール」、SCM (ハウツー)バージョン管理の基礎。
Retrieved from "https://en.wikipedia.org/w/index.php?title=Version_control&oldid=1228320279"