基本情報のバージョン管理をGitの変更例と構成管理で理解する

基本情報のバージョン管理は、「過去のファイルを残すこと」と覚えるだけでは、構成管理や変更管理との区別で迷いやすくなります。まずは、版を追うのがバージョン管理、成果物の組合せを把握するのが構成管理、と役割を分けて考えましょう。

Gitのコミットは変更を履歴に記録する操作、ブランチは作業の流れを分ける仕組み、マージは分かれた変更を統合する操作です。記録・分岐・統合を、図書貸出システムの変更例でたどると関係がつかめます。

この記事では、集中型と分散型の違いから、競合が起きたときの判断、ベースラインとリリースの関係まで整理します。コマンドを暗記する前に、問題文の「何を管理したいのか」を読み取れるようにするのが目標です。

基本情報のバージョン管理と構成管理

版の履歴と組合せを分けて考える

バージョン管理は、管理対象の変更履歴を記録し、過去の状態や変更点を確認できるようにする仕組みです。構成管理は、それを含めて「システムがどの成果物のどの版でできているか」を識別し、整合性を保つための管理として捉えると分かりやすいです。

たとえば、貸出システムのプログラムだけを最新版にしても、設計書が古いままなら、担当者によって理解する仕様が変わります。プログラム、設計書、テスト仕様書をそれぞれ保存するだけでは、どの組合せで動作を確認したのかまでは分かりません。ここに構成管理が必要になります。

学習範囲の根拠になるIPAの基本情報技術者試験シラバスVer.9.2では、ソフトウェア開発管理技術の「構成管理・変更管理」で構成品目の組合せや状況・履歴の管理を扱っています。冊子の61〜62ページが該当箇所です。

なお、ここで扱うGitは、その管理を具体的にイメージするための例です。Gitを使うこと自体が構成管理の完成を意味するわけではありません。誰が変更を承認するか、どの版を出荷するか、必要な文書がそろっているかは、別途ルールを決めて運用します。

着目すること	管理の考え方	貸出システムでの例
一つの成果物がどう変わったか	バージョン管理	貸出上限を3冊から5冊に変えた履歴を残す
何と何を組み合わせるか	構成管理	コードの版と設計書・テスト仕様書の版を対応させる
変更を認めてよいか	変更管理	上限変更の影響を調べ、承認を経て反映する

問題文に「いつ、誰が、何を変えたか」があれば履歴、「どの版を組み合わせたか」があれば構成、「影響を調べ承認する」があれば変更の統制に注目します。実際の活動は重なりますが、設問が求める目的を先に読むと選択肢を絞れます。

構成品目はコード以外も対象になる

構成品目とは、構成管理の対象として識別して管理するものです。必ずしも一つのソースファイルだけを指しません。プログラムのまとまり、設計文書、設定など、管理上どの単位で識別するかを決めます。対象を何でも無差別に増やすより、再現や確認に必要なものを明らかにすることが大切です。

説明用の図書貸出システムで、貸出上限を変更するケースを考えます。利用者向け画面だけに「5冊まで」と表示しても、判定処理が3冊のままなら期待どおりに動きません。さらに、テスト仕様書が3冊のままなら、旧仕様で合格判定を出してしまいます。

管理する対象	変更前の例	変更後の例
要件・設計文書	一般利用者は3冊まで	一般利用者は5冊まで
上限判定のコード	上限値3で判定	上限値5で判定
画面の説明	3冊まで借りられます	5冊まで借りられます
テスト仕様	3冊は許可、4冊は拒否	5冊は許可、6冊は拒否

この表の版をそれぞれ識別し、「リリース1.1は、この設計書とこのコードとこのテスト結果の組合せ」と追えるようにします。個々のファイル名に「最終版」と付けるだけでは、後から同名のファイルが差し替わり、組合せが曖昧になりがちです。識別子と履歴を対応させる方が確実です。

実行環境や利用ライブラリの版が影響するなら、その情報も再現に必要になります。ただし、認証情報や利用者の個人情報を、説明用だからとリポジトリへ入れてよいわけではありません。管理対象を把握することと、すべての実データを同じ場所に保存することは分けて考えてください。

試験学習では、コードの最新版を選ぶだけで解決するのか、それとも文書や関連部品との一貫性まで求めているのかを確認しましょう。後者なら、個々の履歴を見るだけでは答えが足りません。

集中型と分散型は履歴の置き方が違う

バージョン管理システムには、集中型と分散型があります。大きな違いは、履歴を持つリポジトリの置き方です。集中型は中央のリポジトリを中心に管理し、分散型は各開発者の手元にもリポジトリを持ちます。Gitは分散型の代表例です。

Git公式のバージョン管理の説明でも、集中型と分散型の構成が整理されています。通常のGitの複製では履歴を手元に取得できるため、通信できない間も、取得済みの履歴を調べたり、ローカルでコミットしたりできます。

比較点	集中型の基本構成	分散型の基本構成
履歴を管理する場所	中央のリポジトリを中心に管理	各開発者もローカルリポジトリを持つ
履歴への新しい記録	中央への接続を伴う方式が基本	ローカルへ記録してから共有できる
通信できない間	中央を必要とする操作が制限される	手元の記録・履歴参照などを続けられる
代表例	Subversionなど	Gitなど

集中型でも手元のファイルを編集することはできます。「ネットにつながらなければ何もできない」と丸暗記すると誤りになります。一方、分散型でも、まだ受け取っていない他人の変更を確認したり、自分の変更をリモートへ送ったりするには通信が必要です。何の操作が可能かを区別しましょう。

また、Gitを使うチームが共有用のサーバーを一つ決めても、Gitが集中型へ変わるわけではありません。各自が履歴を持つ仕組みと、運用上の共有先を一つにする方針は別です。GitHubなどのサービスは、共有先や共同作業の機能を提供しますが、Gitと同じ名前のソフトウェアではありません。

細部として、履歴を限定して取得する複製方法もあります。初学者はまず「分散型では手元にも履歴を持ち、記録と共有を分けられる」という基本を押さえれば十分です。すべての複製が必ず全履歴を持つ、とまで断定しないようにしましょう。

保存・コミット・共有は別の状態

Gitでファイルを編集して保存しても、それだけでコミットにはなりません。作業用のファイルを置く場所をワーキングツリー、次のコミットに含める内容を準備する場所をステージングエリア、履歴を記録する場所をリポジトリと呼びます。保存した変更のうち何を履歴に残すかを選べる構造です。

上限を5冊に変えるため、判定処理と画面文言を編集したとします。編集途中でファイルを保存すれば、その作業内容は手元に残ります。その後、今回の変更としてまとめたい内容をステージし、コミットすると、その時点の記録がローカルの履歴に加わります。

コミットは、記録対象の状態に加え、作成者情報やメッセージなどを持ち、識別子で区別されます。学習上は「意味のある変更を後からたどるための記録」と理解しましょう。内部ではプロジェクトのスナップショットを表し、単に画面で見える差分一覧だけを保存するものではありません。

仕組みはGit公式の変更記録の解説で確認できます。ここでは「保存＝コミット」でも「ステージ＝コミット済み」でもない点を押さえてください。

さらに、ローカルのコミットを作っただけでは共有先へ自動で送られません。プッシュはローカル側のコミットなどをリモートへ送る操作です。反対に、リモートの情報を取得するフェッチも、作業中のブランチへ変更を統合することとは区別します。共有の役割はGit公式のリモート操作の説明を参照できます。

「自宅で通信せずに修正をコミットし、出社後に共有する」という状況なら、手元の履歴へ記録する段階と、他の人が取得できるようにする段階の二つがあります。問題文がどちらを指すのかを確認すると、コミットとプッシュの取り違えを防げます。

コミットした内容が自動的に正しい仕様になるわけでもありません。誤った上限値を記録すれば、誤った状態の履歴が残ります。履歴を残す機能と、レビューやテストで内容を確かめる活動は役割が違います。

ブランチで変更の流れを分ける

ブランチは、開発の流れを分けて進める仕組みです。Gitでは、あるコミットを指す参照として管理され、コミットを積み重ねるとその位置が進みます。フォルダ一式を手作業で複製する、と考えるよりも、共通の履歴から別の変更を進める目印、と捉える方が正確です。

貸出システムの安定した版を出発点に、担当Aは貸出上限の変更、担当Bは検索画面の改善に取り組むとします。同じ作業の流れで途中の変更を混ぜると、上限変更だけを先に取り込みたいときに困ります。そこで、目的ごとにブランチを分けて、それぞれコミットを積み重ねます。

この例では、基準のコミットCから、上限変更のコミットA1と、検索改善のコミットB1が別々に生まれます。Aの変更が完成したら先に統合し、Bの作業は続けられます。ブランチを分けた時点で開発内容が自動で承認されるわけではなく、取り込む判断はレビューやテストなどの結果を踏まえます。

また、mainというブランチ名だから必ず本番と同じ状態、という決まりがGitにあるわけではありません。mainを安定版として扱うか、リリース前の開発を含めるかはチームの運用です。名前だけで安全性を決めず、問題文に示された役割を読みましょう。

短い周期で変更を積み重ねる開発でも、履歴や統合の管理は必要です。開発の進め方まで整理したい場合は、基本情報のアジャイルとスクラムの違いも合わせて確認すると、開発手法と管理の仕組みを切り分けられます。

基本情報のバージョン管理を変更例で確認

マージと競合は判断の範囲が違う

マージは、別の開発の流れで進めた変更を統合する操作です。分岐後に一方だけが進んだ場合は、統合先の参照を先へ進めるだけのファストフォワードで済むことがあります。両方が進んだ場合は、共通の祖先と両側の変更を比べて統合するのが基本的な考え方です。

たとえば、担当Aが貸出上限の判定処理を変更し、担当Bが検索画面の説明を修正したなら、変更が干渉せず自動で統合できることがあります。ただし、異なるファイルなら絶対に問題がない、という意味ではありません。処理どうしの関係が変われば動作上の不整合は起こり得ます。

競合、またはコンフリクトは、Gitが変更内容を自動で統合できず、人の判断が必要になった状態です。同じ箇所を別々の内容に変えた場合が典型例で、ファイルを一方が削除し、他方が変更した場合などにも起こり得ます。

基準では「一般利用者の貸出上限は3冊」とします。担当Aは上限を5冊へ変更し、担当Bは同じ設定を2冊へ変更しました。この二つを統合するとき、Gitはどちらが正しい業務ルールかを判断できません。更新日時が新しい方を無条件に採るのではなく、承認済みの要件を確認して採用する内容を決めます。

Aは一般利用者向け、Bは特別な利用区分向けだったなら、そもそも一つの上限値にまとめる設計を変える必要があるかもしれません。片方の数字を消すだけでは、片方の目的が失われます。競合解消では変更の意図を確認し、統合後の内容を整え、検証して記録することが必要です。

マージの仕組みと競合の例はGit公式のブランチとマージの解説で確認できます。「マージすれば必ず競合する」「競合が出なければ正しい」というどちらの考え方も避けましょう。

自動マージできても、画面は5冊、処理は3冊という不整合が残ることはあります。構文として統合できることと、利用者が期待する動作になることは違うため、統合後のテストが必要です。入力の境界を確かめる考え方は、基本情報のテスト技法と同値分割・境界値の考え方で補えます。

ベースラインは承認された基準

構成管理でのベースラインは、ある時点で合意・承認され、以後の変更や比較の基準となる構成です。単に今いちばん新しいファイル、作業途中の保存先、変更できないファイル、という意味ではありません。

基準の考え方はNASAの構成管理の解説でも示されています。ここではNASA固有の手順を試験の正解として覚えるのではなく、基準の構成を明らかにし、そこからの変更を管理する、という概念を参考にします。

貸出システムの例なら、「設計書第2版、コードのコミットC、テスト仕様書第3版、確認済みのテスト結果」を一組として承認し、リリース1.0の基準にするイメージです。開発中に新しいコミットが作られても、そのすべてが直ちに承認済みの基準へ入るわけではありません。

上限5冊への変更が認められたら、対象の文書とコードを更新し、影響するテストを行い、新しい構成を識別します。ベースラインは変更を永久に禁止するためではなく、何を基準に何を変えたのかを追えるようにするためにあります。

Gitのタグは、特定のコミットに名前を付けて識別するために使えます。リリースのコードを示す手段にはなりますが、タグを付けただけで文書の整合性や変更の承認が保証されるわけではありません。タグの役割はGit公式のタグの説明で確認できます。

コミット・タグ・ベースライン・リリースを一つの言葉にまとめないようにしましょう。コミットは履歴の記録、タグは特定の記録を識別する名前、ベースラインは管理上の基準、リリースは利用できる版として提供する活動やその版を指します。関連して使われても、役割は同じではありません。

変更要求から出荷までを追跡する

変更管理を具体化するには、コードを編集する前後で、何を確認するかを順に考えると理解しやすくなります。以下は貸出上限の変更を説明するための例で、特定の会社の実際の運用記録ではありません。

段階	この例で行うこと	追えるようにする情報
要求を受ける	上限を3冊から5冊へ変えたい理由を確認	要求内容、対象利用者、希望時期
影響を調べる	画面、判定処理、文書、テストへの影響を洗い出す	対象となる構成品目と現在の版
判断する	影響や対応範囲を踏まえ変更を承認する	承認の結果と条件
変更する	ブランチで修正し履歴を記録する	要求に対応するコミット
確認して提供する	統合後の検証と構成確認を経て出荷する	テスト結果、提供した版の組合せ

大切なのは、変更要求と成果物を結び付けることです。「コミットA1はどの要求への対応か」「リリース1.1にはA1が含まれるか」「そのときのテスト仕様書はどの版か」とたどれれば、不具合が見つかったときの調査範囲を絞れます。このように対応関係を追える性質をトレーサビリティと呼びます。

反対に、要求書だけに承認があり、どのコードへ反映されたか分からない状態では、承認どおりに変更したか確かめにくくなります。コードの履歴だけが完璧でも、どの利用者へどの版を提供したか分からなければ、問い合わせの再現が難しくなります。

不具合対応で過去のコードへ戻す場面も同じです。コードだけ戻して、データの形式や関連設定が新しいままなら、元の動作を再現できない場合があります。「履歴があるから何でも安全に元へ戻せる」とは考えず、その版を動かすために必要な組合せと影響を確かめます。

試験では、日程を守ることが中心なら進捗管理、期待した動作か確かめることが中心なら品質の確認、成果物の版と対応関係を維持することが中心なら構成管理、というように目的を整理してください。管理活動は協力して行うもので、どれか一つを導入すれば他が不要になるわけではありません。

自作の確認問題で目的を見分ける

ここまでの内容を、四つの短い場面で確認します。以下はこの記事の説明用に作成した自作問題で、IPAの過去問題を転載したものではありません。答えを見る前に、「履歴・組合せ・統合・承認基準」のどれが中心か考えてみてください。

問1：開発者が通信できない場所で修正内容をコミットし、翌日にチームの共有先へ送った。この説明から分かるGitの特徴として、適切なものはどれでしょう。アは「記録には必ず中央への接続が要る」、イは「手元の記録と共有を分けられる」、ウは「コミットすれば他の人の作業内容も自動更新される」です。

答えはイです。ローカルリポジトリへの記録は、その場で共有先に接続することと別です。アは分散型の基本と合わず、ウは他の人への配布や取り込みを省略しています。通信の有無だけでなく、どこに何を記録した段階なのかを読み取るのがポイントです。

問2：出荷したシステムの不具合を調べるため、プログラム、設計書、テスト仕様書の対応する版を特定したい。最も直接関わるものはどれでしょう。アは構成管理、イは作業工数の集計、ウは納期の調整です。

答えはアです。探しているのは作業にかかった時間でも、今後の日程でもなく、そのシステムを構成する成果物の組合せです。「各ファイルの最新版を取る」という対応では、実際に出荷した組合せと違ってしまう可能性があります。提供した版を再現するという目的を押さえましょう。

問3：二つのブランチを自動マージできたので、担当者が「機能上の矛盾もない」と判断した。この判断は適切でしょうか。貸出画面の上限表示と、上限判定の処理は別ファイルで管理されています。

適切とはいえません。テキスト上の変更を統合できても、表示と判定が異なる上限になっているかもしれません。競合の検出は、業務要件への適合を保証するテストではありません。表示が5冊なら、5冊を借りられ、6冊目を拒否するかなど、統合した機能として確認する必要があります。

問4：承認済みのリリース1.0の構成と、開発途中の最新コミットがある。「新しい方だから」という理由で最新コミットをリリース1.0の基準として扱ってよいでしょうか。

その理由だけでは扱えません。最新であることと、そのリリースの基準として承認されていることは別です。承認された構成を特定し、変更手順に従って新しい基準を管理します。設問で「ベースライン」が出たら、時刻の新旧よりも、何の基準として合意されているかを確認しましょう。

基本情報のバージョン管理の要点

基本情報のバージョン管理は、用語と操作を一対一で丸暗記するより、対象の状態がどう変わったかで考えると整理できます。保存は作業内容をファイルへ残すこと、コミットは履歴への記録、ブランチは作業の流れの分岐、マージはその統合です。共有先へ送ることは、履歴を手元に記録することと別の段階になります。

構成管理の判断では、一つのファイルだけでなく、必要な成果物の版と組合せを見ます。競合したときは変更の意図と要件を確認し、自動マージできたときも機能の整合性をテストします。ベースラインは承認済みの基準であり、常に最新のコミットを意味するわけではありません。

復習では、貸出上限の変更を自分で説明してみてください。「何を変更するか」「何を履歴に残すか」「どの作業を分けるか」「何を統合・検証するか」「どの組合せを提供するか」の五つを言えれば、用語の関係がつかめています。迷った言葉だけを戻って読み直すと効率的です。

次に選択肢を読み分ける練習へ進むなら、基本情報の過去問演習アプリで科目Aや分野を選んで取り組めます。この本文の自作問題で判断軸を確認したあと、開発技術などの問題で、用語を選ぶ理由まで説明できるか試してみてください。