バージョン管理

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェアエンジニアリングではバージョン管理(リビジョン管理ソース管理、またはソースコード管理とも呼ばれます)は、コンピュータープログラム、ドキュメント、大規模なWebサイト、またはその他の情報コレクションへの変更を管理するシステムのクラスです。バージョン管理は、ソフトウェア構成管理のコンポーネントです。[1]

変更は通常、「改訂番号」、「改訂レベル」、または単に「改訂」と呼ばれる番号または文字コードによって識別されます。たとえば、ファイルの初期セットは「リビジョン1」です。最初の変更が行われると、結果のセットは「リビジョン2」になり、以下同様に続きます。各リビジョンは、タイムスタンプと変更を行った人に関連付けられています。リビジョンを比較、復元し、一部の種類のファイルとマージすることができます。

執筆が存在する限り、リビジョンを整理および制御する論理的な方法の必要性は存在していましたが、コンピューティングの時代が始まると、リビジョン管理ははるかに重要で複雑になりました。本の版の番号付け仕様の改訂の番号付けは、印刷のみの時代にさかのぼる例です。今日、最も有能な(そして複雑な)リビジョン管理システムは、ソフトウェア開発で使用されるシステムであり、チームが同じファイルに同時に変更を加えることができます。

バージョン管理システムVCS)は、最も一般的にはスタンドアロンアプリケーションとして実行されますが、リビジョン管理は、ワードプロセッサスプレッドシート、共同Webドキュメント[2]などのさまざまな種類のソフトウェアや、Wikipediaなどのさまざまなコンテンツ管理システムに組み込まれています。ページ履歴リビジョン管理により、ドキュメントを以前のリビジョンに戻すことができます。これは、編集者が互いの編集を追跡し、間違いを修正しWikiでの破壊行為やスパムから保護するために重要です。

概要

コンピュータソフトウェアエンジニアリングでは、リビジョン管理は、ソースコードへの変更を追跡して制御するあらゆる種類の手法ですソフトウェア開発者は、ソースコードだけでなく、 ドキュメントや構成ファイルを維持するためにリビジョン管理ソフトウェアを使用することがあります。

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

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

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

リビジョン管理は、Unixシステムに通常保存されているものなどの構成ファイルへの変更を追跡する場合ありますこれにより、システム管理者は、加えられた変更を簡単に追跡する別の方法と、必要に応じて以前のバージョンにロールバックする方法を利用できます。 /etc/usr/local/etc

歴史

IBMのOS / 360 IEBUPDTEソフトウェア更新ツールは1962年にさかのぼり、おそらくVCSツールの前身です。ソースコード管理用に設計された完全なシステムが1972年に開始され、同じシステム(OS / 360)用のSCCSが開始されました。1975年12月4日に公開されたSCCSの紹介は、歴史的に、それが最初の意図的な改訂管理システムであることを暗示していました。[3] RCSはその直後に続き、[4]ネットワークバージョンのCVSが続きました。CVSの次の世代はSubversionによって支配され[5] 、 Gitなど分散型リビジョン管理ツールが登場しました。[6]

構造

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

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

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

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

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

グラフ構造

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

グラフ理論の観点から、改訂は一般に、これから分岐した開発ライン(トランク)として考えられ、方向付けられたツリーを形成し、1つ以上の平行な開発ライン(ブランチの「メインライン」)の分岐として視覚化されますトランクから。実際には、構造はより複雑で、有向非巡回グラフを形成しますが、多くの目的では、「マージ付きのツリー」が適切な近似値です。

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

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

分散リビジョン管理では、複数のリポジトリが存在する場合、これらは単一の元のバージョン(ツリーのルート)に基づく場合がありますが、元のルートは必要ないため、リポジトリごとに個別のルート(最も古いリビジョン)のみが必要です。たとえば、2人が別々にプロジェクトに取り組み始めた場合。同様に、データを交換またはマージする複数のデータセット(複数のプロジェクト)が存在する場合、単一のルートはありませんが、簡単にするために、1つのプロジェクトをプライマリ、もう1つのプロジェクトをセカンダリと見なし、最初のプロジェクトにマージするかどうかを指定します。独自の改訂履歴。

専門的な戦略

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

バージョン管理は、ビジネスや法律で広く使用されています。実際、「契約レッドライン」と「リーガルブラックライン」は改訂管理の最も初期の形式の一部であり[7]、現在でもさまざまな程度の洗練度でビジネスや法律に採用されています。CADファイルへの変更の電子追跡(製品データ管理を参照)に最も洗練された手法が使用され始めており、従来のリビジョン管理の「手動」電子実装に取って代わります。[要出典]

ソース管理モデル

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

不可分操作

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

ファイルロック

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

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

バージョンマージ

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

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

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

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

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

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

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

構成管理の最も正式な議論では、ベースラインという用語を使用します

分散リビジョン管理

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

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

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

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

統合

より高度なリビジョン管理ツールのいくつかは、他の多くの機能を提供し、他のツールやソフトウェアエンジニアリングプロセスとのより深い統合を可能にします。プラグインは、 Oracle JDeveloperIntelliJ IDEAEclipseVisualStudioなどのIDEで利用できることがよくありますDelphiNetBeans IDEXcode、およびGNU Emacs(vc.el経由)。高度な研究のプロトタイプは適切なコミットメッセージを生成しますが[10]、コミットメッセージはプロジェクトの慣習や特異性に大きく依存しているため、すでに大きな歴史を持つプロジェクトでのみ機能します。[11]

一般的な用語

用語はシステムごとに異なりますが、一般的な使用法には次のようなものがあります。[12]

ベースライン
後続の変更を行うことができるドキュメントまたはソースファイルの承認されたリビジョン。ベースライン、ラベル、タグを参照してください
避難
特定の行を最後に変更した作成者とリビジョンの検索。
ブランチ
バージョン管理下にあるファイルのセットは、ある時点で分岐または分岐される可能性があるため、その時点から、これらのファイルの2つのコピーが、互いに独立して異なる速度または異なる方法で開発される可能性があります。
変化する
変更(またはdiff、またはdelta)は、バージョン管理下にあるドキュメントへの特定の変更を表します変更と見なされる変更の粒度は、バージョン管理システムによって異なります。
変更リスト
アトミックな複数変更コミットを使用する多くのバージョン管理システムでは、変更リスト(またはCL)、変更セット更新、またはパッチは、単一のコミットで行われた変更のセットを識別します。これは、ソースコードのシーケンシャルビューを表すこともでき、特定のチェンジリストIDの時点でソースを調べることができます。
チェックアウト
チェックアウト(またはco)とは、リポジトリからローカルの作業コピーを作成することですユーザーは、特定のリビジョンを指定するか、最新のものを入手できます。「チェックアウト」という用語は、作業コピーを説明する名詞としても使用できます。共有ファイルサーバーからファイルがチェックアウトされている場合、他のユーザーがファイルを編集することはできません。ホテルのように考えてください。チェックアウトすると、その設備を利用できなくなります。
クローン
クローン作成とは、別のリポジトリからのリビジョンを含むリポジトリを作成することを意味します。これは、空の(新しく初期化された)リポジトリにプッシュまたはプルするのと同じです。名詞として、2つのリポジトリは、同期が維持され、同じリビジョンが含まれている場合、クローンであると言えます。
コミット(名詞)
「コミット」または「リビジョン」(SVN)は、リポジトリに適用される変更です。
コミット(動詞)
コミットチェックインci、またはまれにインストール送信記録)とは、作業コピーで行われた変更をリポジトリに書き込むかマージすることですコミットには、メタデータ、通常は作成者情報と変更を説明するコミットメッセージが含まれます。
対立
異なる関係者が同じドキュメントに変更を加え、システムが変更を調整できない場合、競合が発生します。ユーザーは、変更を組み合わせるか、一方の変更を選択して他方を優先することにより、競合を解決する必要があります。
デルタ圧縮
ほとんどのリビジョン管理ソフトウェアは、ファイルの連続するバージョン間の違いのみを保持するデルタ圧縮を使用します。これにより、さまざまなバージョンのファイルをより効率的に保存できます。
ダイナミックストリーム
一部またはすべてのファイルバージョンが親ストリームのバージョンのミラーであるストリーム。
輸出
エクスポートは、リポジトリからファイルを取得する行為です。チェックアウトと似ていますが、作業コピーで使用されるバージョン管理メタデータなしでクリーンなディレクトリツリーが作成される点が異なります。これは、たとえば、コンテンツを公開する前によく使用されます。
フェッチ
プルを参照してください
前方統合
メイントランクで行われた変更を開発(機能またはチーム)ブランチにマージするプロセス。
ヒントとも呼ばれます。これは、トランクまたはブランチのいずれかに対する最新のコミットを指します。トランクと各ブランチには独自のヘッドがありますが、HEADはトランクを指すために大まかに使用されることがあります。[13]
輸入
インポートとは、ローカルディレクトリツリー(現在は作業コピーではない)をリポジトリに初めてコピーすることです。
初期化
新しい空のリポジトリを作成します。
インターリーブされたデルタ
一部のリビジョン管理ソフトウェアは、インターリーブデルタを使用します。これは、デルタ圧縮を使用するよりも効率的な方法でテキストベースのファイルの履歴を保存できる方法です
ラベル
タグを参照してください
ロック
開発者がファイルをロックすると、ロックが解除されるまで、他の誰もそのファイルを更新できません。ロックは、バージョン管理システムによって、または開発者間の非公式の通信(別名ソーシャルロック)を介してサポートできます。
メインライン
トランクに似ていますが、ブランチごとにメインラインが存在する場合があります。
マージ
マージまたは統合は、2セットの変更が1つのファイルまたは1セットのファイルに適用される操作です。いくつかのサンプルシナリオは次のとおりです。
  • 一連のファイルで作業しているユーザーが、他のユーザーによって行われた変更で作業コピーを更新または同期し、リポジトリにチェックインします。[14]
  • ユーザーは、ファイルがチェックアウトされてから他のユーザーによって更新されたファイルをチェックインしようとしますリビジョン管理ソフトウェアは、ファイルを自動的にマージします(通常、自動マージを続行するかどうかをユーザーに確認した後、場合によってはのみマージが明確かつ合理的に解決できる場合はそうします)。
  • ブランチが作成され、ファイル内のコードが個別に編集され、更新されたブランチは後で単一の統合トランクに組み込まれます
  • ファイルのセットが分岐します。これは、分岐が一方のブランチで修正される前に存在していた問題であり、修正は次にもう一方のブランチにマージされます。(このタイプの選択的マージは、前のケースの完全なマージと区別するために、チェリーピックと呼ばれることもあります。)
促進
管理されていない場所から管理されている場所にファイルコンテンツをコピーする行為。たとえば、ユーザーのワークスペースからリポジトリへ、またはストリームからその親へ。[15]
引く、押す
あるリポジトリから別のリポジトリにリビジョンをコピーします。プルは受信リポジトリによって開始され、プッシュはソースによって開始されます。Fetchは、 pullの同義語として、またはpullの後に更新が続くことを意味するために使用されることがあります。
プルリクエスト
「プッシュされた」変更をマージするように他の人に依頼する開発者。
リポジトリ
リポジトリ(または「リポジトリ」)は、ファイルの現在および履歴データが保存される場所であり、多くの場合サーバー上にあります。デポとも呼ばれます。
解決
同じドキュメントへの異なる変更間の競合に対処するためのユーザー介入の行為。
逆統合
さまざまなチームブランチをバージョン管理システムのメイントランクにマージするプロセス。
リビジョン
また、バージョンバージョンはフォームの変更です。SVKでは、リビジョンは、リポジトリ内のツリー全体のある時点での状態です。
シェア
1つのファイルまたはフォルダーを複数のブランチで同時に使用できるようにする行為。共有ファイルが1つのブランチで変更されると、他のブランチでも変更されます。
ストリーム
他のそのようなコンテナとの既知の関係を持つ分岐ファイルのコンテナ。ストリームは階層を形成します。各ストリームは、その親ストリームからさまざまなプロパティ(バージョン、名前空間、ワークフロールール、サブスクライバーなど)を継承できます。
鬼ごっこ
タグまたはラベルは、多くのファイルにわたって一貫性のある、時間内の重要なスナップショットを参照します。その時点でのこれらのファイルはすべて、ユーザーフレンドリーで意味のある名前またはリビジョン番号でタグ付けされている可能性があります。ベースライン、ラベル、タグを参照してください
トランク
ブランチではない独自の開発ライン(ベースライン、メインライン、マスターとも呼ばれます)
アップデート
更新(または同期ただし、同期はプッシュプルの組み合わせを意味する場合もあります)は、リポジトリで(たとえば、他の人が)行った変更をローカルの作業コピーにマージします。 更新は、一部のCMツール(CM +、PLS、SMS)で変更パッケージの概念に使用される用語でもあります(変更リストを参照各リポジトリに正確に1つの作業コピーが必要なリビジョン管理システムのチェックアウトと同義です(分散システムで一般的)
ロックを解除する
ロックを解除します。
ワーキングコピー
作業コピーは、特定の時間またはリビジョンでのリポジトリからのファイルのローカルコピーですリポジトリ内のファイルに対して行われるすべての作業は、最初は作業コピーで行われるため、この名前が付けられています。概念的には、サンドボックスです。

も参照してください

メモ

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

参考文献

  1. ^ a b c O'Sullivan、ブライアン(2009)。Mercurial:決定的なガイドセバストポル:O'Reilly Media、Inc。ISBN 97805965554742015年9月4日取得
  2. ^ GoogleDocs」、ファイルの変更点を確認、Google Inc.
  3. ^ Rochkind、Marc J.(1975)。「ソースコード管理システム」(PDF)ソフトウェアエンジニアリングに関するIEEEトランザクションSE-1(4):364–370。土井10.1109 /TSE.1975.6312866S2CID10006076_  
  4. ^ Tichy、Walter F.(1985)。「Rcs—バージョン管理のためのシステム」ソフトウェア:実践と経験15(7):637–654。土井10.1002 /spe.4380150703ISSN0038-0644_ S2CID2605086_  
  5. ^ コリンズ-サスマン、ベン; フィッツパトリック、BW; Pilato、CM(2004)、Subversionを使用したバージョン管理、O'Reilly、ISBN 0-596-00448-6
  6. ^ レーリガー、ジョン; マッカロー、マシュー(2012)。Gitによるバージョン管理:共同ソフトウェア開発のための強力なツールとテクニックオライリーメディア。pp。2–5。ISBN 9781449345044
  7. ^ エンジニアリング図面については、ホワイトプリント#ドキュメントコントロールを参照してください。たとえば、ヒューズエアクラフトエンジニアリング手順など、20世紀に導入された手動システムの一部については、ローレンスA.ハイランドによる承認が必要です米国政府によって制定された承認手順も参照してください。
  8. ^ スマート、ジョン・ファーガソン(2008)。Java動力工具「O'ReillyMedia、Inc。」。p。301. ISBN 97814919545462019年7月20日取得
  9. ^ ウィーラー、デビッド。「オープンソースソフトウェア/フリーソフトウェア(OSS / FS)ソフトウェア構成管理(SCM)システムに関するコメント」2007年5月8日取得
  10. ^ Cortes-Coy、Luis Fernando; リナレス-バスケス、マリオ; アポンテ、ジャイロ; Poshyvanyk、Denys(2014)。「ソースコードの変更の要約によるコミットメッセージの自動生成について」。2014 IEEE 14th International Working Conference on Source Code Analysis andManipulationIEEE。pp。275–284。土井10.1109 /scam.2014.14ISBN 978-1-4799-6148-1S2CID360545 _
  11. ^ Etemadi、Khashayar; モンペラス、マーティン(2020-06-27)。「コミットメッセージ生成のための最も近い隣人とのクロスプロジェクト学習の関連性について」。ソフトウェアエンジニアリングワークショップに関するIEEE / ACM第42回国際会議の議事録大韓民国ソウル:ACM。pp。470–475。arXiv2010.01924土井10.1145 /3387940.3391488ISBN 9781450379632S2CID221911386 _
  12. ^ Wingerd、Laura(2005)。実用的なPERFORCEオライリー。ISBN 0-596-10185-6
  13. ^ グレゴリー、ゲイリー(2011年2月3日)。「バージョン管理システムにおけるトランクとHEAD」Java、Eclipse、およびその他の技術情報2012年12月16日取得
  14. ^ Collins-Sussman、Fitzpatrick&Pilato 2004、1.5:SVNツアーサイクルの解決: 'GはmerGedを表します。つまり、ファイルには最初からローカルの変更がありましたが、リポジトリからの変更はローカルと重複していませんでした。変化します。」
  15. ^ コンセプトマニュアル(バージョン4.7版)。Accurev。2008年7月。

外部リンク

  • 「バージョン管理のビジュアルガイド」、より適切に説明
  • シンク、エリック、「ソース管理」、SCM(ハウツー)バージョン管理の基本。