バージョン管理ツールの運用に関する次の記述を読んで，設問に答えよ。
A社は，業務システムの開発を行う企業で，システムの新規開発のほか，リリース後のシステムの運用保守や機能追加の案件も請け負っている。A社では，ソースコードの管理のために，バージョン管理ツールを利用している。
バージョン管理ツールには，1人の開発者がファイルの編集を開始するときにロックを獲得し，他者による編集を禁止する方式（以下，ロック方式という）と，編集は複数の開発者が任意のタイミングで行い，編集完了後に他者による編集内容とマージする方式（以下，コピー・マージ方式という）がある。また，バージョン管理ツールには，ある時点以降のソースコードの変更内容の履歴を分岐させて管理する機能がある。以降，分岐元，及び分岐して管理される，変更内容の履歴をブランチと呼ぶ。
ロック方式では，編集開始時にロックを獲得し，他者による編集を禁止する。編集終了時には変更内容をリポジトリに反映し，ロックを解除する。ロック方式では，つのファイルを同時に1人しか編集できないので，複数の開発者で開発する際に変更箇所の競合が発生しない一方，①開発者間で作業の待ちが発生してしまう場合がある。
A社では，規模の大きな改修に複数人で取り組むことも多いので，コピー・マージ方式のバージョン管理ツールを採用している。A社で採用しているバージョン管理ツールでは，開発者は，社内に設置されているバージョン管理ツールのサーバ（以下，サーバという）のリポジトリの複製を，開発者のPC上のローカル環境のリポジトリとして取り込んで開発作業を行う。編集時にソースコードに施した変更内容は，ローカル環境のリポジトリに反映される。ローカル環境のリポジトリに反映された変更内容は，編集完了時にサーバのリポジトリに反映させる。サーバのリポジトリに反映された変更内容を，別の開発者が自分のローカル環境のリポジトリに取り込むことで，変更内容の開発者間での共有が可能となる。
コピー・マージ方式では，開発者間で作業の待ちが発生することはないが，他者の変更箇所と同一の箇所に変更を加えた場合には競合が発生する。その場合には，ソースコードの変更内容をサーバのリポジトリに反映させる際に，競合を解決する必要がある。競合の解決とは，同一箇所が変更されたソースコードについて，それぞれの変更内容を確認し，必要に応じてソースコードを修正することである。
A社で使うバージョン管理ツールの主な機能を表1に示す。
| コマンド | 説明 |
| ブランチ作成 | あるブランチから分岐させて，新たなブランチを作成する。 |
| プル | サーバのリポジトリに反映された変更内容を，ローカル環境のリポジトリに反映させる。 |
| コミット | ソースコードの変更内容を，ローカル環境のリポジトリに反映させる。 |
| マージ | ローカル環境において，あるブランチでの変更内容を，他のブランチに併合する。 |
| プッシュ | ローカル環境のリポジトリに反映された変更内容を，サーバのリポジトリに反映させる。 |
| リバート | 指定したコミットで対象となった変更内容を打ち消す変更内容を生成し，ロカル環境のリポジトリにコミットして反映させる。 |
| 注記 A社では，ローカル環境での変更内容を，サーバのリポジトリに即時に反映させるために，コミット又はマージを行ったときに，併せてプッシュも行うことにしている。 | |
開発案件を担当するプロジェクトマネージャのM氏は，ブランチの運用ルールを決めてバージョン管理を行っている。取り扱うブランチの種類を表2に，ブランチの運用ルールを図1に，ブランチの樹形図を図2に示す。
| 種類 | 説明 |
| main | システムの運用環境にリリースする際に用いるソースコードを，永続的に管理するブランチ。 このブランチへの反映は，他のブランチからのマージによってだけ行われ，このブランチで管理するソースコードの直接の編集，コミットは行わない。 |
| develop | 開発の主軸とするブランチ。開発した全てのソースコードの変更内容をマージした状態とする。 mainブランチと同じく，このブランチ上で管理するソースコードの直接の編集，コミットは行わない。 |
| feature | 開発者が個々に用意するブランチ。担当の機能についての開発とテストが完了したら，変更内容をdevelopブランチにマージする。その後に不具合が検出された場合は，このブランチ上で確認・修正し，再度developブランチにマージする。 |
| release | リリース作業用に一時的に作成・利用するブランチ。developブランチから分岐させて作成し，このブランチのソースコードで動作確認を行う。不具合が検出された場合には，このブランチ上で修正を行う。 |
・開発案件開始時に，mainブランチからdevelopブランチを作成し，サーバのリポジトリに反映させる。
・開発者は，サーバのリポジトリの複製をローカル環境に取り込み，ローカル環境でdevelopブランチからfeatureブランチを作成する。ブランチ名は任意である。
・featureブランチで機能の開発が終了したら，開発者自身がローカル環境でテストを実施する。
・開発したプログラムについてレビューを実施し，問題がなければfeatureブランチの変更内容をローカル環境のdevelopブランチにマージしてサーバのリポジトリにプッシュする。・サーバのdevelopブランチのソースコードでテストを実施する。問題が検出されたら，ローカル環境のfeatureブランチで修正し，変更内容をdevelopブランチに再度マージしサーバのリポジトリにプッシュする。テスト完了後，featureブランチは削除する。
・開発案件に関する全てのfeatureブランチがサーバのリポジトリのdevelopブランチにマージされ，テストが完了したら，サーバのdevelopブランチをローカル環境にプルしてからreleaseブランチを作成し，テストを実施する。検出された問題の修正はreleaseブランチで行う。テストが完了したら，変更内容を a ブランチと b ブランチにマージし，サーバのリポジトリにプッシュして，releaseブランチは削除する。
図1 ブランチの運用ルール
図2 ブランチの樹形図
A社が請け負ったある開発案件では，A，B，Cの三つの機能を既存のリリース済のシステムに追加することになった。
A，B，Cの三つの追加機能の開発を開始するに当たり，開発者2名がアサインされた。機能AとCはI氏が，機能BはK氏が開発を担当する。開発の流れを図3に示す。
図3 開発の流れ
I氏は，機能Aの開発のために，ローカル環境で a ブランチからfeature-Aブランチを作成し開発を開始した。I氏は，機能Aについて（ア），（ウ），（オ）の3回のコミットを行ったところで，（ウ）でコミットした変更内容では問題があることに気が付いた。そこでI氏は，（α）のタイミングで，②（ア）のコミットの直後の状態に滞りなく戻すための作業を行い，編集をやり直すことにした。プログラムに必要な修正を加えた上で c した後，③テストを実施し，問題がないことを確認した。その後，レビューを実施し， a ブランチにマージした。
機能Bは機能Aと同時に開発を開始したが，規模が大きく，開発の完了は機能A，Cの開発完了後になった。K氏は，機能Bについてのテストとレビューの後，ローカル環境上の a ブランチにマージし，サーバのリポジトリにプッシュしようとしたところ，競合が発生した。サーバのリポジトリから a ブランチをプルし，その内容を確認して競合を解決した。その後，ローカル環境上の a ブランチを，サーバのリポジトリにプッシュしてからテストを実施し，問題がないことを確認した。
全ての変更内容をdevelopブランチに反映後，releaseブランチをdevelopブランチから作成して④テストを実施した。テストで検出された不具合を修正し，releaseブランチにコミットした後，再度テストを実施し，問題がないことを確認した。修正内容を a ブランチと b ブランチにマージし， b ブランチの内容でシステムの運用環境を更新した。
feature-Bブランチのように，ブランチ作成からマージまでが長いと，サーバのリポジトリ上のdevelopブランチとの差が広がり，競合が発生しやすくなる。そこで，レビュー完了後のマージで競合が発生しにくくするために，随時，サーバのリポジトリからdevelopブランチをプルした上で，⑤ある操作を行うことを運用ルールに追加した。
出典：令和5年度春期 問8
設問1 本文中の下線①について，他の開発者による何の操作を待つ必要が発生するのか。10字以内で答えよ。
解答・解説
解答例
ロックの解除
解説
設問2 図1及び本文中の a 〜 c に入れる適切な字句を答えよ。
解答・解説
解答例
a：develop b：main c：コミット
解説
設問3 本文中の下線②で行った作業の内容を，表1中のコマンド名と図3中の字句を用いて40字以内で具体的に答えよ。
解答・解説
解答例
（オ）のコミットをリバートし，次に（ウ）のコミットをリバートする。
解説
設問4 本文中の下線③，④について，実施するテストの種類を，それぞれ解答群の中から選び記号で答えよ。
- 開発機能と関連する別の機能とのインタフェースを確認する結合テスト
- 開発機能の範囲に関する，ユーザーによる受入れテスト
- プログラムの変更箇所が意図どおりに動作するかを確認する単体テスト
- 変更箇所以外も含めたシステム全体のリグレッションテスト
解答・解説
解答例
下線③：ウ 下線④：エ
解説
設問5 本文中の下線⑤について，追加した運用ルールで行う操作は何か。表2の種類を用いて，40字以内で答えよ。
解答・解説
解答例
developブランチの内容をfeatureブランチにマージする。
解説
IPA公開情報
出題趣旨
システムを開発するに当たって，ソースコードの構成管理を適切に行うことは非常に重要である。
本問では，バージョン管理ツールのブランチ運用ルールを題材に，バージョン管理ツールの機能や特徴についての基本的な理解と応用力を問う。
採点講評
問 8 では，バージョン管理ツールのブランチ運用ルールを題材に，バージョン管理ツールの機能や特徴について出題した。全体として正答率は平均的であった。
設問 3 は，正答率が低かった。ソースコードに加えられた複数の変更内容について，それらを打ち消すための操作を問うたが，操作の順序についての理解が不足していると思われる解答が散見された。ソースコードのバージョン管理を行うに当たっては，変更内容のほか，変更が加えられた順番を意識することも重要である。
設問 4 の下線④は，正答率が平均的であった。ブランチの役割と，それぞれのタイミングにおける状態を考慮しながら，行うべき作業の内容を正しく判断できるようになってほしい。
設問 5 は，正答率が低かった。複数の開発者が関わるプロジェクトの場合，それぞれのブランチの役割を逸脱しないように運用することが非常に重要である。どのタイミングで，どのブランチに対して操作を行うべき かを正しく判断できるよう，理解を深めてほしい。
