ソースコードを複数人で編集していると、「誰がいつ何を変更したのか」が分からなくなります。
この混乱を防ぐために生まれたのが、Git と Subversion に代表されるバージョン管理システムです。
対象試験と出題頻度
Git / Subversion は、応用情報技術者（AP）の午前問題で出題されるテーマです。
近年は構成管理ツールの定番として、ソフトウェア構成管理の文脈で問われます。
「分散型と集中型の違い」「コミットとプッシュの役割」「マージとブランチの基本概念」が頻出ポイントです。
詳細をクリックして確認
応用情報技術者
★★☆☆☆
ランクC（応用）余裕があれば覚える
用語の定義
情報処理試験を勉強していると、「Gitは分散型、Subversionは集中型って言われるけど、結局どう違うの？」と混乱しがちです。
Git / Subversion（SVN）とは、一言で言うと
「ソースコードの変更履歴を記録・管理するためのバージョン管理システム（VCS）の代表的な2種類」
のことです。
イメージとしては、「図書館の貸出方式の違い」です。
Subversion は「中央図書館に1冊だけ本があり、利用者は必要なページを借りに行く」方式。Git は「全員が図書館の完全コピーを自宅に持っていて、各自で読み書きしてから中央と同期する」方式です。
同じ「本（ソースコード）」を扱いますが、保管場所と作業のしかたがまったく違います。
📊 Git / Subversion の基本情報
| 項目 | Git | Subversion |
|---|---|---|
| 方式 | 分散型（DVCS） | 集中型（CVCS） |
| 初版リリース | 2005年 | 2000年 |
| 開発元 | Linus Torvalds 他 | Apache Software Foundation |
| 代表的なホスティング | GitHub、GitLab、Bitbucket | Apache SVN サーバ |
解説
複数人で同じファイルを編集すると、上書き合戦が起きて変更が消える事故が起きます。これを防ぐため、変更履歴を時系列で保存し、誰の変更が何行目に入ったかを記録する仕組みが必要になりました。
これがバージョン管理システムの存在理由です。
集中型（Subversion）の仕組み
サーバ上にただ一つの「リポジトリ（変更履歴の保管庫）」を置き、開発者はそこから必要なファイルを取り出して編集し、サーバへ書き戻します。
履歴はサーバ側にしか存在しません。
［集中型：Subversion］
分散型（Git）の仕組み
各開発者の手元に「リポジトリ全体のコピー」が存在します。普段の commit はローカルリポジトリに対して行い、共有したくなったタイミングでリモートリポジトリへ push します。
ネットワーク非接続でも履歴の参照やコミットが可能です。
［分散型：Git］
2つの方式の比較
| 比較項目 | Subversion（集中型） | Git（分散型） |
|---|---|---|
| 履歴の保管場所 | 中央サーバのみ | 各開発者＋リモート |
| オフライン作業 | 不可（commit にネット必要） | 可能 |
| ブランチの作成 | ディレクトリ単位（コスト高） | 軽量・高速 |
| サーバ障害時 | 作業継続困難 | ローカルで作業継続可 |
| 学習コスト | 低い（操作が直感的） | 高い（概念が多い） |
代表的なコマンド対応表
# Subversion の基本フロー
$ svn checkout https://example.com/repo # 作業コピー取得
$ svn update # 最新を取り込み
$ svn commit -m “修正内容” # 中央へ反映
# Git の基本フロー
$ git clone https://example.com/repo.git # リポジトリ複製
$ git pull # 最新を取り込み
$ git add . # 変更をステージ
$ git commit -m “修正内容” # ローカルへ記録
$ git push origin main # リモートへ反映
Git では「ローカルへの記録（commit）」と「リモートへの送信（push）」が分かれている点が、Subversion との最大の操作上の違いです。
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 Git / Subversion の核心を3行で
・どちらもバージョン管理システム。Subversion は集中型、Git は分散型
・集中型は履歴がサーバ1箇所、分散型は各開発者の手元にも履歴の完全コピーがある
・Git では「ローカルへ記録（commit）」と「リモートへ送信（push）」が独立している
試験ではこう出る！
応用情報技術者試験の午前では、構成管理ツールの特徴を問う形で出題されます。出題パターンは大きく3つです。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R元秋 午前 問49 |
分散型バージョン管理システムの特徴を選ぶ問題。 | ・「各開発者がリポジトリの完全な複製を持つ」が正解 ・「常にサーバへ接続が必要」は集中型の説明でひっかけ |
| AP H30秋 午前 問49 |
構成管理ツールで管理する対象を選ぶ問題。 | ・「ソースコードと設計書」が正解 ・実行中のプロセス情報は対象外 |
| AP H29春 午前 問49 |
バージョン管理での「マージ」の説明を選ぶ問題。 | ・「分岐したブランチを統合する操作」が正解 ・チェックアウト・コミットとの混同に注意 |
📝 IPA試験での出題パターン
パターン1：「分散型の特徴を選べ」
「各クライアントがリポジトリ全体の複製を保持する」がGit型の正解選択肢。「中央サーバが唯一の履歴保管場所」「サーバへの接続が常に必要」はSubversion型の説明でひっかけ。
パターン2：「コミット・プッシュ・マージの定義を選べ」
commit＝変更を記録、push＝リモートへ送信、merge＝ブランチの統合、checkout＝作業対象の切り替え。これらの操作名と動作の対応を入れ替えたひっかけ選択肢が頻出。
パターン3：「構成管理の対象を選べ」
ソースコード・設計書・テストデータなど成果物の世代管理が対象。CPU使用率や稼働中プロセスは対象外。
試験ではここまででOKです。具体的なコマンドオプションや内部のオブジェクト構造（blob・tree・commitオブジェクト）まで深追いする必要はありません。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. Git に代表される分散型バージョン管理システムの特徴として、最も適切なものはどれでしょうか？
- A. 中央サーバ上の唯一のリポジトリにのみ変更履歴が保存され、開発者はサーバへ接続している間だけ履歴を閲覧できる。
- B. ファイル単位で排他ロックを取得した開発者だけが編集でき、他の開発者は読み取り専用となる。
- C. 各開発者がリポジトリ全体の完全な複製を手元に持ち、ネットワーク非接続でもコミットや履歴参照が可能である。
正解と解説を見る
正解：C
解説：
分散型バージョン管理システムでは、各クライアントがリポジトリの全履歴を含む完全な複製を保持します。これにより、サーバとの通信なしでローカルでのコミットや履歴参照が可能になり、サーバ障害時にも作業を継続できます。
選択肢Aは集中型（Subversion）の特徴の説明であり、分散型ではなく集中型の説明としては正しい内容です。選択肢Bは「ロック型」と呼ばれる古い世代の管理方式（VSS等）の説明で、Git や Subversion 標準の運用方式ではありません。Subversion はロック機能を持ちますが、原則は「コピー＆マージ型」で動作します。
よくある質問（FAQ）
Q. GitHub と Git は同じものですか？
違います。Git は手元のPCでも動作するバージョン管理ソフトウェアそのものです。GitHub は Git のリモートリポジトリをインターネット上でホスティングするウェブサービスで、米Microsoftが運営しています。同種のサービスに GitLab・Bitbucket があります。Git を使うのに GitHub は必須ではありません。
Q. Subversion はもう使われていないのですか？
現役で使われています。新規プロジェクトでの採用はGitに置き換わりつつありますが、長く運用されてきた業務システム、官公庁のプロジェクト、ゲーム開発などのバイナリ大容量ファイルを扱う現場では今もSubversionが選ばれます。Subversion はバイナリの差分管理が得意で、ロック機能で同時編集を防ぎやすいという強みがあるためです。
Q. ブランチとタグは何が違いますか？
ブランチは「これから変更を加えていく開発ラインの分岐」、タグは「ある時点のスナップショットに付ける固定的な目印」です。例えば「v1.0リリース時点のソースコード」にタグを打ち、その後の改修は別ブランチで進める、という使い分けをします。タグは原則変更しない一方、ブランチは継続的にコミットが追加される点が決定的な違いです。
Q. コンフリクト（競合）が発生したらどうしますか？
複数人が同じ行を別々に編集してマージした際に発生します。解決手順は、競合箇所をエディタで開き、自分の変更と相手の変更のどちらを残すか（または両方を活かすか）を判断して手動編集し、再度コミットします。Git では git status で競合ファイルを確認、Subversion では svn status で「C」マークが付いたファイルが対象になります。実務では事前に pull／update で最新を取り込んでから編集を始めるのが鉄則です。
