ソフトウェア構成管理//バージョン管理

こんにちは。



SCM-ソフトウェア構成管理に関する一連の記事を公開し続けています。

同じブログで以前の3つのメモを読むことができます。



今日は、ほとんどの読者が使用しているバージョン管理について説明します。

免責事項

以下では、ほとんどのバージョン管理システムに実装されている主な手法について説明します。 読者が使用するアプリケーションでそれらをどのように実装するかは、多数のユーザーガイド、ハウツー、FAQ、およびその他の簡単に見つけられるドキュメントに翻弄されます。 主なことは、どのような原則とそれがそのように機能するのかを理解することです。

何言ってるの？

バージョン管理システムは、要素のバージョンを作成し、これらのバージョンを独立した要素として使用できるソフトウェアです。 英語のソースでは、 バージョン管理システム （略してVCS）という用語が使用されています。 バージョンの操作には、バージョン自体の作成とバージョンの保存構造の両方が含まれます。 原則として、これらはチェーンまたはツリーのいずれかです。



要素とそのバージョンを使用する前に、これらの要素を作成する必要があります。 利用可能な実世界のオブジェクトを取得し、それらを制御下に置くようにバージョン管理システムに指示します。 要素自体と一緒に、最初のバージョンが常に作成されます。

ほとんどの場合、バージョン管理の要素は次のとおりです。

• ファイル
• ディレクトリ
• ハードリンクとソフトリンク。

制御システム内では、要素自体をさまざまな方法で配置できます。これは、VCSアーキテクトによって異なります。 ユーザーにとって重要なのは、要素がストア内に配置され、選択されたツールキットのコマンドを使用して作業が実行されることだけです。

バージョンの分岐とマージ

すでに述べたように、制御システムはバージョンを保存するための構造を提供する必要があります。 この構造の最も一般的な表現は、 バージョンツリーです。 これは、構成要素の任意のバージョンに基づいて、そのバージョンのシーケンスのいくつかのセットを作成できる要素のバージョンのそのような組織です。 この場合、任意のバージョンに由来するバージョンの別個のセットはブランチと呼ばれます。 また、ブランチにはバージョンが含まれているため、各バージョンは他のブランチを作成するためのソースになります。 要するに、ツリー。



モデルの名前はそれ自体を物語っています：植物（要素）にはつぼみと葉（バージョン）があり、その中に枝があります。 枝-葉（他のバージョン）および他の枝。 繰り返しますが、同じ植生が成長します。 その結果、樹冠が多数のバージョンであるツリーが成長します。 1つの要素-1つのツリー。



なぜこの構造全体が必要なのですか？ 単純にバージョンを1つずつビルドすることは本当に不可能ですか？ もちろんできます。 ただし、これにより、そのようなシステムの使用がすぐに制限されます。 バージョンが1つずつ表示される場合、ある時点では、システムで作業しているユーザーのうち1人だけが新しいバージョンを作成でき、残りは待機する必要があります。 さらに、新しいバージョンが表示されると、誰もが自分の変更を現在の開発と組み合わせる必要があります。 そして、すべての来訪者がベストプラクティスをバージョンチェーンに組み込むまでです。 この場合、バージョンのマージがシステムの故障につながらないことを確認する必要があります。 さらに、すべての変更がこのような方法で制御されるまで、待機しているすべてのユーザーは、現在作業中のものと混同することなく、中間結果をローカルに保存する必要があります。 そして、数人の人々が数十の要素に取り組んでいる場合、彼らは常に同意することができます。 そして、スケールがはるかに大きい場合はどうなりますか？ 数十人を追加します（要素の数を増やすこともありません）-このような単純なチェーンは、作業を完全に妨げます。 一般に、バージョンの線形構造は多くの複雑さをもたらします。



ですから、枝なしではできないことは明らかです。 しかし、開発者の最小くしゃみで同じブランチを成長させませんか？ どのような場合にブランチが成長するかを見てみましょう。 ブランチの典型的な例は次のとおりです。

• 変更要求のブランチ-変更要求の作業中に作成されたバージョンに対して開始されます（ "development"または "syarny"ブランチ）。
• 統合ブランチ-安定化プロセスの中間ストレージとして機能します。
• リリースブランチ-構成を安定させながらバージョンをレイアウトするため（記事の最初の部分の対応するセクションを参照）。 ブランチの一部のバージョンは、後で基本構成の一部として宣言できます。
• デバッグ（「デバッグ」）ブランチ-主に意思決定をチェックする目的で、バージョンの短期保管用。

スキーム1. element.c要素のバージョンツリー



図1は、バージョンツリーの例を示しています。 element.cファイルにはリリースブランチrelease_1.xがあり、このエレメントの安定バージョンが追加されます（1〜5）。 デルタを保存するために、変更要求ごとに特別な名前形式の個別のブランチが作成されます。 この場合、形式はrec <record_number> _ <username>です。ここで、record_numberは追跡システムの変更要求のIDです。 異なる開発者からのデルタを結合するために、int_ <username> _ <suffix>という形式の名前を持つ統合ブランチが作成されます。サフィックスには統合の説明または安定化された構成の番号が格納されます。 デバッグ用のブランチも見ることができます。ほとんどの場合、それらはdbg_ <username> _ <arbitrary_commentation>と呼ばれます-変更の検証バリアントがレイアウトされています。



この例の各ブランチの成長に関する詳細については、以下で説明します。

各プロジェクトには、ブランチを作成して名前を付ける独自の方法がありますが、主なものは上記にリストされています。 製品ラインを使用する場合、これらすべてのタイプを使用する必要があります。



バージョンツリーは成長および拡大しており、遅かれ早かれ作業の結果を組み合わせる必要があります。 たとえば、開発者が要素の1つからブランチを作成して、変更要求を処理しました。 彼はそれにいくつかのバージョンを置きました。後者はデバッグおよびテストされたコードを含むものです。 同時に、リリースブランチがあります。ここには、基本構成および安定リリースの一部としてリリースされるバージョンがあります。 結果を組み合わせる必要があります。



このために、 バージョンマージメカニズムが使用されます。 原則として、選択されたブランチ（ベース）でベースバージョンが取得され、選択されたサードパーティバージョン（ソース）に含まれる変更が適用される要素の新しいバージョンを作成することを意味します。 英語のソースでは、 マージという用語が使用されます。



ソースバージョンを持つブランチは、ソースバージョンと以前の祖先の両方から成長できます。 既存のVCSでは、手動と自動の両方をマージできます。 また、2番目の方法が主な方法です。 手動マージは、競合の場合にのみ要求されます。



要素の両方のバージョンで同じフラグメントが変更されると、 マージの競合が発生します。 この状況は、ソースバージョンの祖先が新しいバージョンの成長元のバージョンではない場合に発生します。 このような競合の典型的な例は、ソースファイルの先頭に追加される改訂履歴です。これにより、各バージョンで、誰が最後に変更したか、何が行われたかをすぐに確認できます。 異なるソースから作成されたバージョンをマージする場合、この行は間違いなく競合を引き起こし、ストーリーに両方の行を挿入することによってのみ解決されます。 より複雑なケースが発生した場合、影響を受けるコードの開発者または専門家は、必要な変更を慎重に手動で行う必要があります。



共通の祖先と変更のマージの問題：手動および自動に加えて、マージは2ポジションおよび3ポジションの方法で実行できます。 オンオフマージは 、単に2つのバージョンを比較し、それらのデルタ （要素バージョン間の違い）を加算することによって行われます。 このアルゴリズムは、diff'aの原理またはそれに近い原理で動作します。デルタを取得し、必要な行を挿入/削除/変更します。



3ポジションの合併では、両方のバージョンの「 共通の祖先 」が考慮され、対応するブランチの変更の履歴に基づいてデルタが計算されます。 したがって、合併の競合が発生した場合、開発者には要素の3つのバージョンが提供されます-共通の祖先と2つのオプション、この祖先に何が起こったのか、そして変化します。 このアプローチは、両方のブランチのデルタの程度と重要性を評価し、変更の作成者が参加しなくても、しばしば競合部分を統合する必要性について決定するのに役立ちます。



合併が完了した後、可能であれば、合併に関する情報を保存する必要があります。 原則として、成熟したVCSの大部分は、「マージ矢印」-変更がマージされた場所、場所、時間、および変更を行ったユーザーに関するメタ情報を保存する機能を備えています。

分岐とマージの例

例-スキーム2の要素のバージョンのツリーを考えてみましょう。このツリーでは、ブランチの成長とマージの順序を示しています。 すでに推測できるように、ツリー全体はスキーム1から取得されますが、マージ矢印が追加されます。





スキーム2.異なるブランチ間の変更をマージする例



そのため、プロジェクトは、element.cファイルを含む特定の製品を作成します。 安定バージョンを維持するために、チームはすべての安定バージョンまたはベースバージョンがrelease_1.xブランチに保存されることに同意しました。 これは「 リリースブランチ 」と呼ばれます。 この要素も例外ではなく、リリースブランチで初期バージョン1が作成されます。

簡単にするために、ブランチをディスク上のディレクトリであるかのように説明します。 したがって、最初のバージョンは/release_1.x/1と呼ばれます。



次に、変更要求追跡システム（以下、このシステムを単に「バグトラッカー」と呼びます）のマネージャーの1人がレコード番号98を作成し、製品に必要な新しい機能について説明しました。 そして、もちろん、私はこのタスクを担当するユーザーの1人を任命しました-それをuser2としましょう。 user2はしばらくの間考えてこの問題を解決し始め、しばらくして、結果のソースをバージョン管理下に置くことに決めました。 プロジェクトで採用されている命名基準（CMポリシー）によると、プロジェクトを変更するためのブランチはrec <record-number> _ <user> [_ <comments>]と呼ばれます。 したがって、新しいブランチの名前はrec98_user2になり、その作成者はコメントを控えました。 作業は本格的で、/ release_1.x / rec98_user2 / 1のバージョンが表示され、次に/release_1.x/rec98_user2/2が表示されます。

ここで、user2開発者に任せて、タスクについて考えてみましょう。 結局のところ、彼が働いている間にバグトラッカーで、レコード（CR）が121番の下に登録され、テスターに​​よって発見された新しいエラーを記述しました。 このレコードはユーザーuser1に割り当てられ、説明されているエラーを正常に修正し始めました。 彼が修正したように、彼は結果を保存するためにブランチを作成することにしました。 プロジェクトポリシーに従って、ユーザーは新しいブランチにrec121_user1という名前を付けました。 作業を開始してブランチを作成するときに、誰かが次の安定バージョンをリリースブランチ（/release_1.x/2）に既に追加していることに注意してください。 したがって、ブランチはその時点（2番目）の最後のバージョンから成長します。 ブランチが作成されます-バージョンを追加できます。 最終結果は、バージョン/release_1.x/rec121_user1/2です。



次は？ エラーは修正され、テストされました（この作業平面は今のところ舞台裏に置いておきます）。これらの変更を安定した構成の一部とし、場合によっては新しい基本構成の一部にします。 ここで、CMエンジニアまたはこの役割を実行するチームメンバーの作業を開始します。 合併チームのクローバーとスレッジハンマーを使用して、リリースブランチに新しいバージョン/release_1.x/3を作成します。 番号1の矢印に注意してください-マージプロセスのみが表示されます。



user2に戻りましょう-彼は自分のタスクにいくつかの変更を加えることにしましたが、彼はまず何が起こるかをまとめ、同僚にその解決策を見てもらうことにしました。 これを行うために、彼はデバッグブランチを作成します。 プロジェクトのCMポリシーは、dbg_ <user> [_ <comment>]と呼ばれるべきであると述べています。 したがって、新しいブランチは/release_1.x/rec98_user2/dbg_user2という名前になります。 その上で、ユーザーはバージョン/release_1.x/rec98_user2/dbg_user2/1を作成します。 結果のソリューションをメインコードに組み込むことが決定されたため、作成者は新しいデルタとブランチが成長したバージョンをマージしました。 同時に、ユーザーはコードをクリーンアップおよび最適化して、統合のために返すのが恥ずかしくないようにしました-結果はバージョン/release_1.x/rec98_user2/3でした。 さて、番号2の明るい矢印は、合併プロセスを明確に表しています。



ただし、user2は、作業中に重大なエラーが修正され、CR＃121が解決されたことを発見しました。 また、この修正は新しい機能の機能に影響を与える可能性があります。 両方のデルタを接続し、何が起こるかを確認する決定が下されます。 バージョン/release_1.x/rec98_user2/3と/release_1.x/rec121_user1/2のマージは、バージョン/release_1.x/rec98_user2/4を形成するために行われます。 まあ、数3の合併矢印も表示されます。 この新しいバージョンは、パフォーマンスとエラーをチェックし、決定が下されます-統合する必要があります！ 繰り返しますが、CMエンジニアは自分のツールを使用して/release_1.x/4バージョンを作成し、それに対応する矢印番号4を描画します（数字の一致はランダムです）。



しかし、人生は静止していません。 2人の開発者が協力してデルタをマージしましたが、他のチームメンバーはすでに同じファイルを変更していました。 130個と131個の2つのCRが開かれ、これらはuser3に割り当てられました。 彼はそれらを正常に完了し、レコードごとに1つずつ、2つのブランチを作成しました。 タスクは異なる時間に設定および解決されたため、ソリューションのブランチはリリースブランチの異なるバージョンから成長しました。 結果は、バージョン/release_1.x/rec130_user3/1および/release_1.x/rec131_user3/1であり、バージョン/release_1.x/3から間隔が空いています。



変更があります-すべてがうまくいけば、それらを結合し、安定させ、基本構成を作成する必要があります。 この目的のために、バージョン管理システムの運用エイリアスuser7で実行するCMエンジニアは、このプロジェクトでint_ <user> _ <future-release-number>のような統合ブランチを作成します。 したがって、ブランチ/release_1.x/int_user7_1.5が表示されます。 両方のデルタが一緒にマージされます。 最初に、レコード130の変更、バージョン/release_1.x/int_user7_1.5/1の形成。 次に、131を記録するために、同じブランチ上にバージョン2が作成されます。 すべての操作について、マージ矢印が描画されます。



CMエンジニアの最後のコードは、バージョン/release_1.x/int_user7_1.5/2をリリースブランチにマージして、バージョン/release_1.x/5を形成することです。 その後、このブランチは製品の基本構成の一部になります。

ここに、小さな画像のかなり大きな説明があります。 1枚の写真は数百の言葉に値する-彼らは真実を言う。



気配りのある読者はおそらく頭に疑問を抱いているでしょう。もしすべてがブランチとマージ矢印を介して行われている場合、/ release_1.x / 2バージョンはどこから来たのでしょうか？ 結局のところ、ブランチからの単一の矢印がそれにつながるわけではありません！ 自然な質問。 答えも論理的です。 はい、リリースブランチに直接変更が加えられる場合があります。 たとえば、最初のバージョンで行われたひどい間違いが見つかりました-変更履歴セクションで誰が変更を行ったかについてコメントを忘れていました！ もちろん、これは冗談です、誰もそのような些細なことのために政治に違反しません。 しかし-そしてこれは起こります。 主なことは、誰が新しいバージョンを作成したのか、なぜ彼がそれをしたのかを正確に知ることです。 何よりも、バージョン管理システムで各ブランチのバージョンを個別に作成する権限を制限できる場合。 この場合、リリースブランチにバージョンを追加する許可をCMエンジニアのみに与えることで、プロジェクトをさらに保護します。 少なくともこのような制限があると、最後の1つを見つけやすくなります:)。



上記の後、ブランチを操作する機能は実際には成熟したバージョン管理システムの基本的な機能であると言う必要がありますか？ ブランチがなければ、バージョン管理システムは正式な観点からのみそのように考えることができます-それは単にバージョンを保存して発行できるが、それ以上ではないからです。

タグ

そのため、バージョンツリーは成長しており、チームの作業は順調に進んでいます。 作業結果を安定させ、基本構成を決定する必要があります。基本構成は、いつでもチームメンバーがバージョン管理システムから取得できます。 安定化はバージョンのマージによって行われます-これについては以下で説明します。 しかし、基礎を確立する上で、私たちはより詳細に説明します。

基本設定を取得することは、基本的に安定したバージョンのセットを識別し、それらを一意に識別する方法を決定することです。 これらの目的のために、バージョン管理システムには「タグ付け」メカニズムがあります。 ラベルは、構成を一意に識別する英数字の指定です。 ラベルがあると、構成を常に正確かつ明確に強調表示できる必要があります。

英語の情報源は、主に用語labelとtagを使用します。



ラベルが構成の指定である場合、構成の各バージョンはこのラベルによって一意に識別される必要があります。 したがって、ラベルはそのバージョンの要素を選択し、必要に応じてマークされます。



ラベルの概念の実装は、システムによって異なる場合があります。 一部（CVSからClearCaseまで）では、ラベルは要素のバージョンの属性です。 たとえば、図2では、ラベルはいずれかのバージョンに直接掛けられています。 サークルの横にある単なるタグになります。 他のシステム（Subversion）では、ラベルはブランチの種類の1つにすぎないと理解されています。 それぞれ-彼自身、主なことは、投資された意味が同じままであることです。



私が他に注意したいこと：1つの構成に複数のラベルを付けることができます。 たとえば、記事の最初の部分で説明したコンポーネントには、コンポーネントラベル（コンポーネントの基本構成を決定するため）と製品ラベルの両方をラベル付けして、製品の基本構成の一部として正式に登録できます。 各コンポーネントの基本構成には少なくとも2回マークが付けられています。1回目はコンポーネントラベル、2回目は製品ラベルです。

一般に、ラベルは構成を識別する手段であるため、ほとんどの場合、ラベルはCMエンジニア向けのツールです。 開発者は、追加の作業の基礎を定期的に受け取るために、すでに作成されたタグのみを使用します。

まとめ

バージョン管理システムの基本機能を上に示しました。 特定のアプリケーションでどのように実装されているか-個人的に使用しているシステムで誰でも見ることができます。

全面的な外観でツールをもう一度見て、説明されている内容と比較してください。



伝統-独立した思慮深い読書のための推奨資料のリスト。

1. en.wikipedia.org/wiki/Comparison_of_revision_control_software-既存のバージョン管理システムの優れた比較
2. www.cmcrossroads.com/bradapp/acme/branchingはブランチポリシーに関する優れた記事です。さまざまなプロジェクトに適したさまざまなブランチパターンが考えられます。
3. www.infoq.com/articles/agile-version-control-ブランチの成長とアジャイル手法を使用したマージの整理方法に関する説明記事。 リンクをありがとう。

バージョン管理システムの使用の全体像を完成させるために、地理的に異なる場所にある開発チーム間でのこの管理の分散について話す必要があります。 しかし、それについては次のノートで説明します。



継続する。



PS私は、「バージョン管理システム」ではなく「プロジェクト管理」で公開し、一連のノート全体を統一的な方法で公開しています。