令和5年度 春期 応用情報技術者試験 午後問題 問8 ブランチ運用ルールとリバート・マージの使い方

テクノロジ開発プロセスシステム開発技術

この問題は2023(R5)春 応用情報技術者 午後に出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。

本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています(改行・記号・数式・図表参照の調整)。設問の趣旨および正解に影響する変更は加えていません。

学習ガイド

main・develop・feature・releaseの各ブランチを運用する開発事例です。コミット履歴をブランチ別の時間軸に描き直し、問題のある変更を戻す順序と、競合を解消するためのマージ方向を確認します。テスト工程との対応も併せて整理します。本文・表・図の根拠を行き来し、用語だけを暗記するのではなく、短い記述にも判断の理由を残して解答する手順を示します。

この記事で押さえる論点

  • ロック方式とコピー・マージ方式の違いを作業待ちと競合の観点で説明できる
  • main・develop・feature・releaseの各ブランチの役割から空欄のブランチ名を判断する
  • 複数のコミットを打ち消すときにリバートを新しい順に適用する理由を述べる
  • 長期化したfeatureブランチの競合を減らすためにdevelopを取り込む操作を記述する

問題本文

問8 バージョン管理ツールの運用に関する次の記述を読んで,設問に答えよ。

A社は,業務システムの開発を行う企業で,システムの新規開発のほか,リリース後のシステムの運用保守や機能追加の案件も請け負っている。A社では,ソースコードの管理のために,バージョン管理ツールを利用している。

バージョン管理ツールには,1人の開発者がファイルの編集を開始するときにロックを獲得し,他者による編集を禁止する方式(以下,ロック方式という)と,編集は複数の開発者が任意のタイミングで行い,編集完了後に他者による編集内容とマージする方式(以下,コピー・マージ方式という)がある。また,バージョン管理ツールには,ある時点以降のソースコードの変更内容の履歴を分岐させて管理する機能がある。以降,分岐元,及び分岐して管理される,変更内容の履歴をブランチと呼ぶ。

ロック方式では,編集開始時にロックを獲得し,他者による編集を禁止する。編集終了時には変更内容をリポジトリに反映し,ロックを解除する。ロック方式では,一つのファイルを同時に1人しか編集できないので,複数の開発者で開発する際に変更箇所の競合が発生しない一方,開発者間で作業の待ちが発生してしまう場合がある

A社では,規模の大きな改修に複数人で取り組むことも多いので,コピー・マージ方式のバージョン管理ツールを採用している。A社で採用しているバージョン管理ツールでは,開発者は,社内に設置されているバージョン管理ツールのサーバ(以下,サーバという)のリポジトリの複製を,開発者のPC上のローカル環境のリポジトリとして取り込んで開発作業を行う。編集時にソースコードに施した変更内容は,ローカル環境のリポジトリに反映される。ローカル環境のリポジトリに反映された変更内容は,編集完了時にサーバのリポジトリに反映させる。サーバのリポジトリに反映された変更内容を,別の開発者が自分のローカル環境のリポジトリに取り込むことで,変更内容の開発者間での共有が可能となる。

コピー・マージ方式では,開発者間で作業の待ちが発生することはないが,他者の変更箇所と同一の箇所に変更を加えた場合には競合が発生する。その場合には,ソースコードの変更内容をサーバのリポジトリに反映させる際に,競合を解決する必要がある。競合の解決とは,同一箇所が変更されたソースコードについて,それぞれの変更内容を確認し,必要に応じてソースコードを修正することである。

A社で使うバージョン管理ツールの主な機能を表1に示す。

表1 A社で使うバージョン管理ツールの主な機能
図の説明テキスト
コマンド 説明
ブランチ作成 あるブランチから分岐させて,新たなブランチを作成する。
プル サーバのリポジトリに反映された変更内容を,ローカル環境のリポジトリに反映させる。
コミット ソースコードの変更内容を,ローカル環境のリポジトリに反映させる。
マージ ローカル環境において,あるブランチでの変更内容を,他のブランチに併合する。
プッシュ ローカル環境のリポジトリに反映された変更内容を,サーバのリポジトリに反映させる。
リバート 指定したコミットで対象となった変更内容を打ち消す変更内容を生成し,ローカル環境のリポジトリにコミットして反映させる。

注記 A社では,ローカル環境での変更内容を,サーバのリポジトリに即時に反映させるために,コミット又はマージを行ったときに,併せてプッシュも行うことにしている。

〔ブランチ運用ルール〕

開発案件を担当するプロジェクトマネージャのM氏は,ブランチの運用ルールを決めてバージョン管理を行っている。取り扱うブランチの種類を表2に,ブランチの運用ルールを図1に,ブランチの樹形図を図2に示す。

表2 ブランチの種類
図の説明テキスト
種類 説明
main システムの運用環境にリリースする際に用いるソースコードを,永続的に管理するブランチ。
このブランチへの反映は,他のブランチからのマージによってだけ行われ,このブランチで管理するソースコードの直接の編集,コミットは行わない。
develop 開発の主軸とするブランチ。開発した全てのソースコードの変更内容をマージした状態とする。
main ブランチと同じく,このブランチ上で管理するソースコードの直接の編集,コミットは行わない。
feature 開発者が個々に用意するブランチ。担当の機能についての開発とテストが完了したら,変更内容を develop ブランチにマージする。その後に不具合が検出された場合は,このブランチ上で確認・修正し,再度 develop ブランチにマージする。
release リリース作業用に一時的に作成・利用するブランチ。develop ブランチから分岐させて作成し,このブランチのソースコードで動作確認を行う。不具合が検出された場合には,このブランチ上で修正を行う。
図1 ブランチの運用ルール
図の説明テキスト
  • 開発案件開始時に,main ブランチから develop ブランチを作成し,サーバのリポジトリに反映させる。
  • 開発者は,サーバのリポジトリの複製をローカル環境に取り込み,ローカル環境で develop ブランチから feature ブランチを作成する。ブランチ名は任意である。
  • feature ブランチで機能の開発が終了したら,開発者自身がローカル環境でテストを実施する。
  • 開発したプログラムについてレビューを実施し,問題がなければ feature ブランチの変更内容をローカル環境の develop ブランチにマージしてサーバのリポジトリにプッシュする。
  • サーバの develop ブランチのソースコードでテストを実施する。問題が検出されたら,ローカル環境の feature ブランチで修正し,変更内容を develop ブランチに再度マージしサーバのリポジトリにプッシュする。テスト完了後,feature ブランチは削除する。
  • 開発案件に関する全ての feature ブランチがサーバのリポジトリの develop ブランチにマージされ,テストが完了したら,サーバの develop ブランチをローカル環境にプルしてから release ブランチを作成し,テストを実施する。検出された問題の修正は release ブランチで行う。テストが完了したら,変更内容を a ブランチと b ブランチにマージし,サーバのリポジトリにプッシュして,release ブランチは削除する。
図2 ブランチの樹形図
図の説明テキスト

ブランチの樹形図。main, develop, feature, release の4つのブランチのライフサイクルを示す。
凡例: 〇 コミット, ↑ マージ, ✕ ブランチの削除, ▲ テストの実施, △ レビューの実施

  • mainブランチからdevelopブランチが作成される。
  • developブランチからfeatureブランチが作成され、複数のコミットが行われる。
  • featureブランチでテストとレビュー実施後、developブランチへマージされ、featureブランチは削除される。
  • その後developブランチからreleaseブランチが作成され、テスト、コミット(修正)、テストが実施される。
  • 最後にreleaseブランチからdevelopブランチとmainブランチへマージされ、releaseブランチは削除される。

〔開発案件と開発の流れ〕

A社が請け負ったある開発案件では,A,B,Cの三つの機能を既存のリリース済のシステムに追加することになった。

A,B,Cの三つの追加機能の開発を開始するに当たり,開発者2名がアサインされた。機能AとCはI氏が,機能BはK氏が開発を担当する。開発の流れを図3に示す。

図3 開発の流れ
図の説明テキスト

開発の流れを示す樹形図。main, develop, feature-A, feature-C, feature-B, release ブランチがある。

  • developブランチからfeature-A, feature-C, feature-Bが作成される。
  • feature-Aでは(ア), (ウ), (オ)のコミットが行われ、(α\alpha)の操作後、テスト・レビューを経てdevelopへマージ、削除。
  • feature-Bでは(イ), (エ)のコミット等が行われ、長期開発後テスト・レビューを経てdevelopへマージ、削除。
  • feature-Cもコミット、テスト・レビュー後developへマージ、削除。
  • 全てのfeatureがマージされた後、developからreleaseが作成され、テストや修正コミット後、mainとdevelopへマージされ削除される。

I氏は,機能Aの開発のために,ローカル環境でaブランチからfeature-Aブランチを作成し開発を開始した。I氏は,機能Aについて(ア),(ウ),(オ)の3回のコミットを行ったところで,(ウ)でコミットした変更内容では問題があることに気が付いた。そこでI氏は,(α\alpha)のタイミングで,(ア)のコミットの直後の状態に障りなく戻すための作業を行い,編集をやり直すことにした。プログラムに必要な修正を加えた上でcした後,テストを実施し,問題がないことを確認した。その後,レビューを実施し,aブランチにマージした。

機能Bは機能Aと同時に開発を開始したが,規模が大きく,開発の完了は機能A,Cの開発完了後になった。K氏は,機能Bについてのテストとレビューの後,ローカル環境上のaブランチにマージし,サーバのリポジトリにプッシュしようとしたところ,競合が発生した。サーバのリポジトリからaブランチをプルし,その内容を確認して競合を解決した。その後,ローカル環境上のaブランチを,サーバのリポジトリにプッシュしてからテストを実施し,問題がないことを確認した。

全ての変更内容をdevelopブランチに反映後,releaseブランチをdevelopブランチから作成してテストを実施した。テストで検出された不具合を修正し,releaseブランチにコミットした後,再度テストを実施し,問題がないことを確認した。修正内容をaブランチとbブランチにマージし,bブランチの内容でシステムの運用環境を更新した。

〔運用ルールについての考察〕

feature-Bブランチのように,ブランチ作成からマージまでが長いと,サーバのリポジトリ上のdevelopブランチとの差が広がり,競合が発生しやすくなる。そこで,レビュー完了後のマージで競合が発生しにくくするために,随時,サーバのリポジトリからdevelopブランチをプルした上で,ある操作を行うことを運用ルールに追加した。

設問と解答・解説

設問1

本文中の下線①について,他の開発者による何の操作を待つ必要があるのか。10字以内で答えよ。

模範解答

ロックの解除

採点基準(配点 3点)

知識・理解度(内容)(2点)

  • 2: 「ロックの解除」という操作について正確に言及している。
  • 1: 「ロック」に関する言及はあるが、具体的な解除の操作が明確でない。
  • 0: 言及がない、または誤り。

論理性(構造)(1点)

  • 1: 待つべき対象として文意が通る形で記述されている。
  • 0: 日本語として意味が通らない。

解説

集中型バージョン管理システムにおける排他制御(ロック方式)に関する設問です。
他の開発者がファイルを編集目的で取得(チェックアウト)すると、そのファイルにはロックが掛かります。
そのため、別の開発者が同じファイルを編集するためには、他の開発者による ロックの解除 を待つ必要があります。

高得点のポイント

  • 他の開発者がファイルを手放す操作(ロックの解除)について言及できていること。

設問2

図1及び本文中の ac に入れる適切な字句を答えよ。

(1)

a に入れる適切な字句を答えよ。

模範解答

develop

採点基準(配点 3点)

正確性(内容)(3点)

  • 3: 「develop」と正確に解答している。
  • 1: スペルミスなどがあるが「develop」を意図していることがわかる。
  • 0: 不正解または無解答。

解説

ブランチの役割に関する設問です。
一般的なブランチ運用では、開発の中心となる統合ブランチと、リリース用のブランチ、個別の機能追加用のブランチを分けて管理します。
文脈から、機能追加用のブランチ(feature)の分岐元・統合先となるのは、開発の主軸である develop ブランチとなります。

高得点のポイント

  • 開発用統合ブランチの名称として「develop」を正確に記述できていること。

(2)

b に入れる適切な字句を答えよ。

模範解答

main

採点基準(配点 3点)

正確性(内容)(3点)

  • 3: 「main」と正確に解答している。
  • 1: スペルミスなどがあるが「main」を意図していることがわかる。
  • 0: 不正解または無解答。

解説

リリース用のブランチに関する設問です。
開発が完了し、リリース可能な状態になったソースコードは、本番環境向けの主要なブランチに統合されます。
この役割を担うブランチは一般的に main ブランチと呼ばれます。

高得点のポイント

  • リリース用統合ブランチの名称として「main」を正確に記述できていること。

(3)

c に入れる適切な字句を答えよ。

模範解答

コミット

採点基準(配点 3点)

正確性(内容)(3点)

  • 3: 「コミット」と正確に解答している。
  • 1: 「commit」など表記揺れでの解答。
  • 0: 不正解または無解答。

解説

バージョン管理の基本操作に関する設問です。
ローカルのリポジトリに変更内容を記録する操作を コミット と呼びます。
コミットを行うことで、変更履歴が保存され、後から過去の状態に戻したり、他のブランチと統合したりすることが可能になります。

高得点のポイント

  • バージョン管理システムにおける変更の記録操作として「コミット」を正確に記述できていること。

設問3

本文中の下線②で行った作業の内容を,表1中のコマンド名と図3中の字句を用いて40字以内で具体的に答えよ。

模範解答

(オ)のコミットをリバートし,次に(ウ)のコミットをリバートする。

採点基準(配点 3点)

知識・理解度(内容)(2点)

  • 2: リバートの順番が「(オ)の次に(ウ)」であることが正しく示され、対象が適切である。
  • 1: リバートの操作は示されているが、順番が逆、または指定された字句が不足している。
  • 0: 全く異なる操作や無関係な内容。

論理性(構造)(1点)

  • 1: 指定された文字数内で、作業内容として自然な日本語になっている。
  • 0: 日本語として意味が通らない。

解説

ソースコードの変更内容を打ち消す(リバート)際の正しい操作順序を問う設問です。
複数のコミットをリバートする場合、変更が加えられた順番とは 逆の順序 (新しいコミットから古いコミットの順)でリバートを行う必要があります。
したがって、(ウ)と(オ)のコミットを打ち消すには、新しい(オ)のコミットを先にリバートし、その後に(ウ)のコミットをリバートします。

高得点のポイント

  • コミットを取り消すコマンド「リバート」を用いていること。
  • 新しいコミット(オ)から古いコミット(ウ)の順に操作を適用していることが明記されていること。

設問3は,正答率が低かった。ソースコードに加えられた複数の変更内容について,それらを打ち消すための操作を問うたが,操作の順序についての理解が不足していると思われる解答が散見された。ソースコードのバージョン管理を行うに当たっては,変更内容のほか,変更が加えられた順番を意識することも重要である。

設問4

本文中の下線③について,実施するテストの種類を,それぞれ解答群の中から選び記号で答えよ。

(1)

下線③について,実施するテストの種類を,解答群の中から選び記号で答えよ。

  1. 開発機能と関連する別の機能とのインタフェースを確認する結合テスト
  2. 開発機能の範囲に関する,ユーザーによる受入れテスト
  3. プログラムの変更箇所が意図どおりに動作するかを確認する単体テスト
  4. 変更箇所以外も含めたシステム全体のリグレッションテスト

模範解答

選択肢ウ: プログラムの変更箇所が意図どおりに動作するかを確認する単体テスト

配点 1

解説

下線③のタイミングで実施するテストの種類に関する設問です。
機能追加用ブランチ(feature)での開発が完了したタイミングでは、まずプログラムの変更箇所自体が意図どおりに動作するかを確認する必要があります。
これは 単体テスト に該当します。

各選択肢の解説

  • (結合テスト): 他の機能との連携を確認するテストであり、統合ブランチにマージした後に実施するのが適切です。
  • (受入れテスト): システムが要件を満たしているかユーザーが確認するテストであり、開発・テストがすべて完了した後のリリース前に行われます。
  • (単体テスト): プログラムの変更箇所単体の動作確認であり、このタイミング(featureブランチ)で実施すべき適切なテストです。
  • (リグレッションテスト): 変更箇所以外への影響を確認するテストであり、他の機能と統合された後に実施します。

(2)

下線④について,実施するテストの種類を,解答群の中から選び記号で答えよ。

  1. 開発機能と関連する別の機能とのインタフェースを確認する結合テスト
  2. 開発機能の範囲に関する,ユーザーによる受入れテスト
  3. プログラムの変更箇所が意図どおりに動作するかを確認する単体テスト
  4. 変更箇所以外も含めたシステム全体のリグレッションテスト

模範解答

選択肢エ: 変更箇所以外も含めたシステム全体のリグレッションテスト

配点 1

解説

下線④のタイミングで実施するテストの種類に関する設問です。
featureブランチの変更をdevelopブランチにマージした後は、追加した機能によって既存のシステム全体に悪影響が起きていないかを確認する必要があります。
これを リグレッションテスト(退行テスト) と呼びます。

各選択肢の解説

  • (結合テスト): 機能間の連携テストですが、システム全体のデグレ確認という意味合いではリグレッションテストがより適切です。
  • (受入れテスト): ユーザーによる最終確認であり、この段階では早すぎます。
  • (単体テスト): マージ前のfeatureブランチで行うべきテストです。
  • (リグレッションテスト): 統合によって既存機能が破壊されていないかを確認するテストであり、このタイミングで実施すべき適切なテストです。

設問4の下線④は,正答率が平均的であった。ブランチの役割と,それぞれのタイミングにおける状態を考慮しながら,行うべき作業の内容を正しく判断できるようになってほしい。

設問5

本文中の下線⑤について,追加した運用ルールで行う操作は何か。表2の種類を用いて,40字以内で答えよ。

模範解答

developブランチの内容をfeatureブランチにマージする。

採点基準(配点 3点)

知識・理解度(内容)(2点)

  • 2: 「developブランチの内容をfeatureブランチにマージする」という操作の対象と方向が正確に明記されている。
  • 1: マージ操作には触れているが、ブランチの名称や方向が曖昧である。
  • 0: 誤った操作(コミットなど)や無関係な内容。

論理性(構造)(1点)

  • 1: 操作の対象と結果が論理的に繋がった文として記述されている。
  • 0: 日本語として破綻している。

解説

ブランチの並行開発における運用ルールに関する設問です。
複数の開発者が異なる機能を追加している場合、自分のfeatureブランチをdevelopにマージしようとした際に、既に他の開発者によってdevelopブランチが更新されていることがあります。
コンフリクト(競合)を防止・解決し、最新の状態でテストを行うためには、developブランチの最新内容を自身のfeatureブランチにマージ して取り込む操作が必要です。

高得点のポイント

  • 対象となるブランチ(developブランチ、featureブランチ)の名称が明記されていること。
  • 「developからfeatureへのマージ」という方向性が正しく示されていること。

設問5は,正答率が低かった。複数の開発者が関わるプロジェクトの場合,それぞれのブランチの役割を逸脱しないように運用することが非常に重要である。どのタイミングで,どのブランチに対して操作を行うべきかを正しく判断できるよう,理解を深めてほしい。