Loading article…
バージョン管理（改訂管理、ソース管理、ソースコード管理とも呼ばれる）とは、ソフトウェアエンジニアリングの手法の一つで、コンピュータファイルの履歴における様々なバージョンを管理、整理、追跡するものです。主にソースコードのテキストファイルですが、一般的にはあらゆる種類のファイルが対象となります。
バージョン管理はソフトウェア構成管理の構成要素である。[ 1 ]
バージョン管理システムは、バージョン管理を自動化するソフトウェアツールです。あるいは、バージョン管理は、ワードプロセッサ、スプレッドシート、共同作業ウェブドキュメント[ 2 ]、Wikipediaのページ履歴などのコンテンツ管理システムなどの一部のシステムの機能として組み込まれています。
バージョン管理には、過去のバージョンを表示したり、ファイルを以前のバージョンに戻したりするオプションが含まれています。
チームがソフトウェアを開発する際、同じソフトウェアの複数のバージョンを展開したり、異なる開発者が同時に複数の異なるバージョンに取り組むことはよくあります。 ソフトウェアのバグや機能は、多くの場合、特定のバージョンにのみ存在します（プログラムの開発に伴って、一部の問題が修正され、他の問題が導入されるため）。したがって、バグの特定と修正のためには、ソフトウェアの異なるバージョンを取得して実行し、問題が発生するバージョンを特定できることが非常に重要です。また、ソフトウェアの2つのバージョンを同時に開発する必要がある場合もあります。たとえば、一方のバージョンではバグが修正されているが新機能は追加されていない（ブランチ）、もう一方のバージョンでは新機能の開発が行われている（トランク）といった場合です。
最も単純なレベルでは、開発者はプログラムの異なるバージョンの複数のコピーを保持し、それぞれに適切なラベルを付けるだけで済みます。この単純なアプローチは、多くの大規模ソフトウェアプロジェクトで使用されてきました。この方法は機能するものの、プログラムのほぼ同一のコピーを多数維持する必要があるため非効率的です。これは開発者に高度な自己規律を要求し、しばしばミスにつながります。コードベースが同じであるため、開発者グループに読み取り・書き込み・実行権限を付与する必要があり、コードベースが侵害されないように権限を管理する担当者が必要となり、複雑さが増します。そのため、リビジョン管理プロセスの一部または全部を自動化するシステムが開発されました。これにより、ほとんどの操作手順が抽象化され（一般ユーザーからは隠蔽されます）。
さらに、ソフトウェア開発、法律実務、ビジネス実務、その他の環境において、単一の文書やコード断片を、地理的に分散し、異なる、あるいは相反する利害関係を持つメンバーで構成されるチームによって編集することがますます一般的になっています。このような状況では、文書やコードの変更履歴を追跡し、所有権を明確にする高度な改訂管理機能が非常に役立つ、あるいは不可欠となる可能性があります。
バージョン管理システムは、 Unixシステムなどに保存されている設定ファイルへの変更も追跡できます。これにより、システム管理者は変更内容を容易に追跡し、必要に応じて以前のバージョンに戻すことができます。/etc/usr/local/etc
多くのバージョン管理システムでは、ファイルのバージョンをバージョン番号、バージョン、リビジョン番号、リビジョン、またはリビジョンレベルと呼ばれる数字または文字で識別します。たとえば、ファイルの最初のバージョンはバージョン1かもしれません。ファイルが変更されると、次のバージョンは2になります。各バージョンにはタイムスタンプと変更を行った人物が関連付けられています。リビジョンは比較、復元でき、一部のファイルタイプではマージすることもできます。[ 3 ]
IBMのOS/360ソフトウェア更新ツールIEBUPDTEは1962年に遡り、バージョン管理システムツールの先駆けと言えるでしょう。IBM 360/370のインストールで多用されたソース管理およびバージョン管理パッケージには、The LibrarianとPanvaletがありました。[ 4 ] [ 5 ]
ソースコード管理のために設計された完全なシステムは、1972 年に開始されました。それは、OS/360 用のSource Code Control System (SCCS) です。1975 年 12 月 4 日に公開された SCCS のユーザー マニュアル、特に序文では、これが最初の意図的なリビジョン管理システムであると示唆されています。 [ 6 ] 1982 年にRevision Control System (RCS) が続き[ 7 ]、その後、Concurrent Versions System (CVS) が RCS にネットワーク機能と並行開発機能を追加しました。CVS の後継として主流となったのはSubversionであり[ 8 ]、その後、 Gitなどの分散型バージョン管理ツールが登場しました。[ 9 ]
改訂管理は、時間の経過に伴うデータセットの変更を管理するものです。これらの変更は、さまざまな方法で構造化できます。
データは、ファイルやドキュメントといった多数の個々のアイテムの集合体として捉えられることが多く、個々のファイルへの変更が追跡されます。これはファイルを個別に管理するという考え方に沿ったものですが、ファイル名の変更、分割、結合などによって識別子が変わると問題が発生します。そのため、Gitなどのシステムでは、データ全体への変更を扱います。これは単純な変更には直感的ではありませんが、より複雑な変更を簡素化します。
改訂管理されているデータがチェックアウトによって取得された後、変更された場合、通常は改訂管理システム（リポジトリ）にすぐに反映されるわけではなく、代わりにチェックインまたはコミットする必要があります。改訂管理外のコピーは「作業コピー」と呼ばれます。簡単な例として、コンピュータファイルを編集する場合、編集プログラムによってメモリに格納されているデータが作業コピーであり、ファイルを保存することでコミットされます。具体的には、ドキュメントを印刷し、手動で編集し、後で手動で変更をコンピュータに入力して保存することができます。ソースコード管理の場合、作業コピーは、特定の改訂版のすべてのファイルのコピーであり、通常は開発者のコンピュータにローカルに保存されます。[注1 ]この場合、ファイルを保存しても作業コピーのみが変更され、リポジトリへのチェックインは別の手順です。
複数のユーザーが単一のデータセットまたはドキュメントを共同編集する場合、各ユーザーは（作業コピー内で）データのブランチを暗黙的に作成することになり、後述するようにマージに関する問題が発生します。単純な共同ドキュメント編集であれば、ファイルロックを使用するか、他のユーザーが作業しているドキュメントを一緒に編集しないようにすることで、この問題を回避できます。
改訂管理システムは多くの場合、単一の権威あるデータストア（リポジトリ）を持つ集中型であり、チェックアウトとチェックインはこの中央リポジトリを参照して行われます。一方、分散型改訂管理システムでは、権威あるリポジトリは存在せず、データはどのリポジトリにもチェックアウトおよびチェックインできます。別のリポジトリにチェックインする場合、これはマージまたはパッチとして解釈されます。
グラフ理論の観点から見ると、改訂は一般的に、幹となる開発ラインから枝分かれした有向木として捉えられ、幹から分岐する1本以上の平行な開発ライン（枝の「メインライン」）として視覚化されます。実際には、構造はより複雑で、有向非巡回グラフを形成しますが、多くの目的においては「マージを伴う木」という表現で十分です。
改訂は時間の経過とともに順番に行われるため、改訂番号またはタイムスタンプのいずれかの順序で並べることができます。[注2 ]改訂は過去の改訂に基づいていますが、「既存のテキストをすべて削除し、新しいテキストを挿入する」など、以前の改訂を大部分または完全に置き換えることができます。最も単純なケースでは、分岐や取り消しがないため、各改訂は直前の改訂のみに基づいており、単一の最新バージョンである「HEAD」改訂または先端を持つ単純な線を形成します。グラフ理論の用語では、各改訂を点として、各「派生改訂」関係を矢印（慣例として、古いものから新しいものへ、時間と同じ方向を指す）として描くと、これは線形グラフになります。分岐がある場合、つまり複数の将来の改訂が過去の改訂に基づいている場合、または取り消しがある場合、つまり改訂が直前の改訂よりも古い改訂に依存する場合、結果として得られるグラフは有向木（各ノードは複数の子を持つことができる）であり、子を持たない改訂（「各ブランチの最新の改訂」）に対応する複数の先端を持ちます。[注3 ]原則として、結果として得られる木には優先先端（「メイン」の最新の改訂）は必要なく、さまざまな異なる改訂があるだけでよいのですが、実際には、1 つの先端が一般的に HEAD として識別されます。新しい改訂が HEAD に基づいている場合、それは新しい HEAD として識別されるか、新しいブランチとみなされます。[注4 ]開始から HEAD までの改訂のリスト（グラフ理論の用語では、ツリー内の唯一のパスであり、前述のように線形グラフを形成します）は、幹またはメインラインです。[注5 ]逆に、改訂が複数の以前の改訂に基づいている場合（ノードが複数の親を持つことができる場合）、結果として生じるプロセスはマージと呼ばれ、改訂管理の最も複雑な側面の1つです。これは、複数のブランチ（多くの場合2つですが、それ以上の場合もあります）で変更が発生し、両方の変更を組み込んだ単一のブランチにマージされる場合に最もよく発生します。これらの変更が重複している場合、マージが困難または不可能になり、手動での介入または書き直しが必要になる場合があります。
マージが存在する場合、結果として得られるグラフは、ノードが複数の親を持つことができるため、もはやツリーではなく、ルート付き有向非巡回グラフ（DAG）になります。親は常に過去に遡るためグラフは非巡回であり、最も古いバージョンが存在するためルート付きです。幹が存在すると仮定すると、ブランチからのマージはツリーの「外部」とみなすことができます。ブランチの変更はパッチとしてパッケージ化され、それが（幹の）HEADに適用され、ブランチへの明示的な参照なしに新しいリビジョンが作成され、ツリー構造が維持されます。したがって、バージョン間の実際の関係はDAGを形成しますが、これはツリーにマージを加えたものと考えることができ、幹自体は線です。
分散型リビジョン管理では、複数のリポジトリが存在する場合、それらは単一のオリジナルバージョン（ツリーのルート）に基づいている可能性がありますが、必ずしもオリジナルのルートが存在する必要はありません。代わりに、各リポジトリごとに個別のルート（最古のリビジョン）が存在する場合があります。これは、たとえば、2人が別々にプロジェクトに取り組み始めた場合に発生します。同様に、データを交換またはマージする複数のデータセット（複数のプロジェクト）が存在する場合、単一のルートは存在しませんが、簡略化のために、一方のプロジェクトをプライマリ、もう一方をセカンダリと考え、独自のリビジョン履歴の有無にかかわらず、最初のプロジェクトにマージされると考えることができます。
初期の設計図や青写真の改訂を追跡する形式化されたプロセスから発展したエンジニアリング改訂管理「MIL-STD-100G: エンジニアリング図面の国防総省標準実施基準」(PDF)。米国国防総省。1997年6月9日。 2026年5月16日取得。この管理システムは、設計開発において技術的な行き詰まりが生じた場合に、設計の以前の状態に戻ることを暗黙のうちに可能にした。変更履歴は改訂表を用いて記録された。さらに、図面の変更箇所は改訂マークで強調表示された。
バージョン管理はビジネスや法律の分野で広く普及しています。実際、「契約書の赤線」や「法律文書の黒線」は、最も初期の改訂管理の形態の一部であり、[ 10 ]ビジネスや法律の分野では、さまざまな洗練度で現在も使用されています。最も高度な技術は、 CAD ファイルの変更を電子的に追跡するために使用され始めており(製品データ管理を参照)、従来の改訂管理の「手動」電子実装に取って代わっています。[ 11 ]
ゲーム開発では、多くの場合、大きなバイナリファイルや、異なる分野にわたるチームが協力して作業する必要があります。そのため、ゲームスタジオでは、大きなバイナリファイル、ファイルロック、高速同期を適切にサポートするバージョン管理システムを使用しています。一般的なツールとしては、Perforceや、いくつかの新しいクラウドベースのシステムなどがあります。[ 12 ] [ 13 ]
従来のバージョン管理システムは、すべてのバージョン管理機能が共有サーバー上で実行される集中型モデルを採用しています。2人の開発者が同時に同じファイルを変更しようとした場合、アクセス管理の仕組みがなければ、互いの作業内容を上書きしてしまう可能性があります。集中型バージョン管理システムは、この問題を解決するために、ファイルロックとバージョンマージという2つの異なる「ソース管理モデル」のいずれかを採用しています。
操作が中断されてもシステムが一貫した状態を維持できる場合、その操作はアトミックであると言えます。通常、コミット操作はこの意味で最も重要な操作です。コミットは、変更のグループを確定し、すべてのユーザーが利用できるようにリビジョン管理システムに指示します。すべてのリビジョン管理システムがアトミックコミットを備えているわけではありません。Concurrent Versions System にはこの機能がありません。[ 14 ]
同時アクセス問題を防止する最も簡単な方法は、ファイルをロックして、一度に1人の開発者のみが中央の「リポジトリ」にあるファイルのコピーに書き込みアクセスできるようにすることです。開発者がファイルを「チェックアウト」すると、他の開発者はそのファイルを読み取ることができますが、その開発者が更新版を「チェックイン」するか（またはチェックアウトをキャンセルする）まで、他の誰もそのファイルを変更することはできません。
ファイルロックにはメリットとデメリットの両方があります。大きなファイル（またはファイル群）の多くのセクションにユーザーが大幅な変更を加える場合、マージの競合による問題を防ぐことができます。しかし、ファイルが長期間ロックされたままになっていると、他の開発者がバージョン管理ソフトウェアを迂回してローカルでファイルを変更してしまう可能性があり、他の変更が最終的にチェックインされた際に、手動でのマージ作業が困難になる場合があります。大規模な組織では、開発者がプロジェクト間を移動する際に、ファイルが「チェックアウト」されたままロックされ、忘れ去られてしまうことがあります。これらのツールでは、誰がファイルをチェックアウトしているかを簡単に確認できる場合とできない場合があります。
ほとんどのバージョン管理システムでは、複数の開発者が同時に同じファイルを編集できます。中央リポジトリに変更を「チェックイン」した最初の開発者が必ず成功します。システムによっては、さらに変更を中央リポジトリにマージし、他の開発者がチェックインした際に最初の開発者による変更を保持する機能を提供する場合があります。
2つのファイルをマージするのは非常にデリケートな操作であり、通常はテキストファイルのようにデータ構造が単純な場合にのみ可能です。2つの画像ファイルをマージしても、画像ファイルが生成されない場合もあります。ファイルをチェックインする2人目の開発者は、変更内容が互換性があり、マージ操作によってファイル内に独自の論理エラーが発生しないように、マージ処理に注意を払う必要があります。これらの問題により、自動または半自動のマージ操作は、ファイルタイプ専用のマージプラグインがない限り、主に単純なテキストベースのドキュメントに限定されます。
予約編集の概念は、マージ機能が存在する場合でも、ファイルを排他的書き込みアクセス用に明示的にロックするためのオプション手段を提供する。
ほとんどの改訂管理ツールは、スナップショットを識別するアクション（「プロジェクトにラベルを付ける」）またはスナップショットのレコード（「ベースラインXで試す」）を指すために、これらの類似した用語（ベースライン、ラベル、タグ）のうちの 1 つだけを使用します。通常、ドキュメントや議論では、ベースライン、ラベル、タグのいずれか 1 つだけが使用されます[ 15 ] 。これらは同義語とみなすことができます。
ほとんどのプロジェクトにおいて、公開されたリリース、ブランチ、マイルストーンを示すために使用されるスナップショットなど、一部のスナップショットは他のスナップショットよりも重要です。
ベースラインという用語と、ラベルまたはタグのいずれかが同じ文脈で一緒に使用される場合、ラベルとタグは通常、スナップショットを識別または記録するためのツール内のメカニズムを指し、ベースラインは、特定のラベルまたはタグの重要性が増していることを示します。
分散リビジョン管理システム（DRCS）は、集中型システムのクライアント・サーバー方式とは対照的に、ピアツーピア方式を採用しています。クライアントが同期する単一の中央リポジトリではなく、各ピアのコードベースの作業コピーが正真正銘のリポジトリとなります。[ 16 ]分散リビジョン管理では、ピア間でパッチ（変更セット） を交換することで同期を行います。このため、集中型システムとはいくつかの重要な違いが生じます。
むしろ、コミュニケーションが必要となるのは、他の同僚に対して変更を促したり、変更を促したりする場合に限る。
バージョン管理のメリットを最大限に享受するには、ベストプラクティスに従うことが必要です。ベストプラクティスは、バージョン管理ツールやバージョン管理が適用される分野によって異なる場合があります。ソフトウェア開発で一般的に受け入れられているベストプラクティスには、小さな/段階的な変更を行うこと、 1つのタスクまたは修正のみを含むコミットを行うこと（これに伴い、既存の機能を意図的に壊さずに動作するコードのみをコミットすること）、リリース前にブランチを使用して機能を完成させること、コミットの説明またはコードで何、なぜ、どのように明確になるかを示す明確で説明的なコミットメッセージを書くこと、一貫したブランチ戦略を使用することなどがあります。[ 17 ]コードレビューや自動回帰テストなどの他のソフトウェア開発のベストプラクティスは、バージョン管理のベストプラクティスに従うのに役立つ場合があります。
費用とメリットは、選択するバージョン管理ツールと適用分野によって異なります。本節では、バージョン管理が広く用いられているソフトウェア開発分野について解説します。
バージョン管理ソフトウェアのライセンス費用に加え、バージョン管理の利用には時間と労力も必要です。バージョン管理の基本概念を理解し、選択したバージョン管理ソフトウェアを操作するために必要な技術的な詳細を習得しなければなりません。バージョン管理のベストプラクティスを習得し、組織の既存のソフトウェア開発プラクティスに統合する必要があります。有益な効果を得るためには、ベストプラクティスに従うための規律を維持する上で、経営陣の努力が必要となる場合もあります。
主な利点は、履歴を保持し、変更を元に戻せる機能であり、開発者は変更を簡単に元に戻すことができます。これにより、開発者は既存のコードを壊す恐れをなくし、より多くの実験を行うことができます。[ 18 ]
ブランチングは、デプロイメントとリリース管理に役立ちます。ブランチングとマージ、ソースコードパッチの作成、パッケージ化、ラベル付け、およびコードベースへのパッチの容易な適用により、デプロイメントプロセスのさまざまな段階（開発、テスト、ステージング、本番など）に関連する複数のコードベースの保守と同時開発が簡素化されます。[ 19 ]
バージョン管理によって提供される記録保持、つまり誰が、いつ、なぜ、どのように何をしたかの追跡には、損害軽減、説明責任、プロセスと設計の改善、その他の利点があります。[ 20 ]
バグが発生した場合、いつ何が行われたかを知ることは、どのような問題が存在するか、それがどのくらいの期間存在していたかを特定し、問題の範囲と解決策を決定するのに役立つため、被害の軽減と復旧に役立ちます。[ 21 ]以前のバージョンをインストールしてテストすることで、コードとコミットメッセージの調査によって得られた結論を検証できます。[ 22 ]
バージョン管理はデバッグを大幅に簡素化できます。複数のバージョンにテストケースを適用することで、バグを引き起こした変更を迅速に特定できます。[ 23 ] 開発者はコードベース全体に精通している必要はなく、問題を引き起こしたコードに集中できます。
バージョン管理は、さまざまな方法でコラボレーションを強化します。バージョン管理は、競合する変更、つまり同じコード行に対して行われた互換性のない変更を特定できるため、開発者間の調整の必要性が減ります。[ 24 ]
コミット、ブランチ、および関連するすべてのコミット メッセージとバージョン ラベルをパッケージ化することで、開発者間のコミュニケーションが、その瞬間と時間の経過とともに改善されます。[ 25 ] 即時か遅延かを問わず、より良いコミュニケーションは、コード レビュー プロセス、テスト プロセス、およびソフトウェア開発プロセスのその他の重要な側面を改善することができます。
より高度なバージョン管理ツールの中には、他のツールやソフトウェアエンジニアリングプロセスとのより深い統合を可能にする、多くの機能を提供するものもある。
Oracle JDeveloper、IntelliJ IDEA、Eclipse、Visual Studio、Delphi、NetBeans IDE、Xcode、GNU Emacs (vc.el 経由)などのIDE用のプラグインがよく利用できます。高度な研究プロトタイプは適切なコミット メッセージを生成します。[ 26 ]
用語はシステムによって異なる場合があるが、一般的に使用される用語には次のようなものがある。[ 27 ]
承認された文書またはソースファイルの改訂版で、後続の変更が可能なもの。ベースライン、ラベル、タグを参照してください。
特定の行を最後に修正した著者と改訂者を検索する。
バージョン管理下にある一連のファイルは、ある時点で分岐またはフォークされることがあり、その時点以降、それらのファイルの2つのコピーが互いに独立して異なる速度または異なる方法で開発される可能性がある。
変更（またはdiff、またはdelta ）とは、バージョン管理下にある文書に対する特定の修正を表します。変更とみなされる修正の粒度は、バージョン管理システムによって異なります。
多くのバージョン管理システムでは、アトミックな複数変更コミット機能により、変更リスト（またはCL）、変更セット、アップデート、パッチといった用語が、単一のコミットで行われた変更のセットを識別します。これはソースコードの時系列ビューを表すこともでき、特定の変更リストID時点のソースコードを調べることができます。
チェックアウト（またはco）とは、リポジトリからローカルの作業コピーを作成することです。ユーザーは特定のリビジョンを指定することも、最新版を取得することもできます。「チェックアウト」という用語は、作業コピーを表す名詞としても使用できます。共有ファイルサーバーからファイルがチェックアウトされると、他のユーザーは編集できなくなります。ホテルをチェックアウトすると、ホテルのアメニティを利用できなくなるのと同じようなものです。
クローンとは、別のリポジトリのリビジョンを含むリポジトリを作成することを意味します。これは、空の（新しく初期化された）リポジトリにプッシュまたはプルすることと同等です。名詞としては、2つのリポジトリが同期され、同じリビジョンを含んでいる場合、それらはクローンであると言えます。
コミット（チェックイン、CI、またはまれにインストール、送信、記録）とは、作業コピーで行った変更をリポジトリに書き込む、またはマージすることです。コミットにはメタデータが含まれており、通常は作成者情報と変更内容を説明するコミットメッセージが含まれます。
開発者が作成した短いメモで、コミットとともに保存され、コミットの内容を説明するものです。理想的には、変更を行った理由、変更の効果や目的の説明、変更の仕組みに関する分かりにくい点などが記録されます。
異なる当事者が同じ文書に変更を加えた際に、システムがそれらの変更を整合させることができない場合、競合が発生します。ユーザーは、変更を統合するか、一方の変更を優先させることで、競合を解決する必要があります。
ほとんどのバージョン管理ソフトウェアは、ファイルの連続するバージョン間の差分のみを保持するデルタ圧縮を使用しています。これにより、多数の異なるバージョンのファイルをより効率的に保存できます。
ファイルのバージョンの一部または全部が、親ストリームのバージョンをミラーリングしているストリーム。
エクスポートとは、リポジトリからファイルを取得する操作のことです。チェックアウトと似ていますが、作業コピーで使用されるバージョン管理メタデータを含まない、クリーンなディレクトリツリーを作成する点が異なります。これは、例えばコンテンツを公開する前によく使用されます。
プルを参照してください。
メインブランチで行われた変更を開発ブランチ（機能ブランチまたはチームブランチ）にマージするプロセス。
また、 tipとも呼ばれるこの部分は、トランクまたはブランチへの最新のコミットを指します。トランクと各ブランチにはそれぞれ独自の head がありますが、HEAD はトランクを指すために漠然と使用されることもあります。[ 33 ]
インポートとは、ローカルディレクトリツリー（現在作業コピーではないもの）を初めてリポジトリにコピーする行為のことです。
新しい空のリポジトリを作成します。
一部のバージョン管理ソフトウェアは、インターリーブデルタという方法を使用しています。これは、デルタ圧縮を使用するよりも効率的にテキストベースのファイルの履歴を保存できる方法です。
タグを参照してください。
開発者がファイルをロックすると、ロックが解除されるまで他の誰もそのファイルを更新できなくなります。ロックはバージョン管理システムによってサポートされる場合もあれば、開発者間の非公式なコミュニケーション（いわゆるソーシャルロック）によってサポートされる場合もあります。
トランクに似ていますが、各ブランチにメインラインが存在する場合があります。
マージまたは統合とは、 2つの変更セットを1つのファイルまたはファイルセットに適用する操作のことです。以下にいくつかの例を示します。
ファイルの内容を、管理の緩い場所から管理の緩い場所にコピーする行為。たとえば、ユーザーのワークスペースからリポジトリへ、またはストリームから親へコピーする。[ 35 ]
あるリポジトリから別のリポジトリへリビジョンをコピーします。プルは受信側のリポジトリによって開始され、プッシュは送信側のリポジトリによって開始されます。フェッチはプルの同義語として、またはプルに続いて更新が行われることを意味する場合に使用されることがあります。
分散バージョン管理システムを使用するソースコードリポジトリへの貢献は、一般的にプルリクエスト（マージリクエストとも呼ばれる）によって行われます。[ 36 ]貢献者は、プロジェクトメンテナーにソースコードの変更を取り込むよう要求します。これが「プルリクエスト」という名前の由来です。貢献がソースベースの一部となるためには、メンテナーはプルリクエストをマージする必要があります。 [ 37 ]
開発者はプルリクエストを作成して、新しい変更をメンテナーに通知します。各プルリクエストにはコメントスレッドが関連付けられています。これにより、コードの変更について集中的に議論できます。送信されたプルリクエストは、リポジトリへのアクセス権を持つすべての人に表示されます。プルリクエストは、メンテナーによって承認または拒否されます。[ 38 ]
プルリクエストがレビューされ承認されると、リポジトリにマージされます。確立されたワークフローによっては、公式リリースに含める前にコードをテストする必要がある場合があります。そのため、テストされていないプルリクエストをマージするための特別なブランチを持つプロジェクトもあります。[ 37 ] [ 39 ]他のプロジェクトでは、継続的インテグレーションツールを使用してすべてのプルリクエストに対して自動テストスイートを実行し、レビュー担当者が新しいコードに適切なテストカバレッジがあることを確認します。
同一文書に対する複数の変更間の矛盾を解消するためにユーザーが行う介入行為。
異なるチームのブランチをバージョン管理システムのメインブランチに統合するプロセス。
最近の1つまたは複数の変更を放棄し、対象資料の以前のバージョンに戻すこと。元に戻す理由は多岐にわたり、例えば、以前の編集によって生じたエラーの修正、新たな紛争が解決されるまで問題のない状態に資料を復元すること、スコープクリープの取り消し、回帰テストなどが挙げられます。
バージョンとは、形式上のあらゆる変更を指します。SVKでは、リビジョンとは、リポジトリ内のツリー全体の、ある時点における状態を指します。
1つのファイルまたはフォルダを複数のブランチで同時に利用可能にする行為。共有ファイルが1つのブランチで変更されると、他のブランチでも変更が反映されます。
分岐ファイルを格納するコンテナであり、他の同様のコンテナとの既知の関係を持ちます。ストリームは階層構造を形成し、各ストリームは親ストリームから様々なプロパティ（バージョン、名前空間、ワークフロー規則、サブスクライバーなど）を継承できます。
タグまたはラベルとは、複数のファイルにわたって一貫性のある、ある時点における重要なスナップショットを指します。その時点では、これらのファイルにはすべて、ユーザーにとって分かりやすく意味のある名前またはリビジョン番号が付けられている場合があります。ベースライン、ラベル、タグを参照してください。
幹とは、枝ではない独自の開発ラインのことです（ベースライン、メインライン、マスターとも呼ばれます[ 42 ] [ 43 ]）。
更新（または同期、ただし同期はプッシュとプルの組み合わせを意味する場合もある）は、リポジトリで行われた変更（たとえば、他のユーザーによる変更）をローカルの作業コピーにマージします。 更新は、一部のCMツール（CM+、PLS、SMS）で変更パッケージの概念に使用される用語でもあります（変更リストを参照）。各リポジトリに正確に1つの作業コピーが必要であるリビジョン管理システム（分散システムでよく見られる）では、チェックアウトと同義です。
ロックを解除する。
ワーキングコピーとは、リポジトリ内の特定の時点またはリビジョンにおけるファイルのローカルコピーのことです。リポジトリ内のファイルに対して行われるすべての作業は、最初にワーキングコピー上で行われるため、この名前が付けられています。概念的には、サンドボックスのようなものです。
作業時間で言えば、バージョン管理を使用した場合の 6 ～ 48 倍のコストがかかります。これは、1 人の開発者がいくつかのモデルを巻き戻す場合です。
バージョン管理システムを使用すると、コードをコミットする前に、ファイルを比較し、違いを特定し、必要に応じて変更をマージできます。バージョン管理は、どのバージョンが現在開発、QA、および本番環境にあるかを識別できるため、アプリケーションのビルドを追跡する優れた方法でもあります。
ドキュメントの履歴は、作成者と編集日に関する貴重な情報を提供します。また、変更の目的も示します。最新バージョンで作業する開発者に影響を与え、以前のバージョンで発生した問題を解決するのに役立ちます。ドキュメントの作成者を特定できる機能により、現在のチームはドキュメントを特定の貢献者にリンクできます。これにより、現在のチームはバグの修正に役立つパターンを発見できます。これは、ソフトウェアの全体的な機能を向上させるのに役立ちます。
ソフトウェアチームは、コードレビューを通じて以前のバージョンを調べることで、ソリューションの進化を理解できます。
が発生した場合、開発者は時間を遡ってコードの以前のイテレーションを確認し、すべてのチームメンバーへの影響を最小限に抑えながら間違いを修正できます。
bisect ツールは、自動バイナリ検索を実行することで、バグや問題を最初に導入した特定のコミットを見つけるために使用される、非常に便利なデバッグ ツールです。
バージョン管理は、特に複数の開発者が単一のアプリケーションに取り組んでいる場合、非常に貴重なプロセスです。なぜなら、バージョン管理によって開発者が簡単にファイルを共有できるからです。バージョン管理がないと、開発者は最終的に互いの作業を妨害し、気づかないうちに他の誰かが完了したコードの変更を上書きしてしまう可能性があります。これらのシステムを使用すると、変更のためにファイルをチェックアウトし、チェックイン時に、ファイルが他のユーザーによって変更されている場合は、アラートが表示され、それらをマージすることができます。
rebase、merge、および/または squash の使用に関する議論が続いています。私は、これらのすべての選択肢の要点であるコミュニケーションに焦点を当てたいと思います。