まず結論

バージョン管理システム(VCS)はファイルの変更履歴を管理し、過去の状態に戻したり複数人で同時開発したりする仕組みです。現在のデファクトスタンダードはGit(分散型VCS)です。

バージョン管理の種類

集中型VCS(CVS・Subversionなど)

リポジトリが中央サーバーに1つ。オフライン作業不可。サーバー障害で作業停止。
例:SVN(Subversion)

分散型VCS(Git)

各開発者がフルコピーを持つ。オフライン作業可。高速。ブランチ管理が強力。
現在の主流。

Gitの操作フロー

作業ディレクトリ
(ファイル編集)
git add →
ステージング
(コミット準備)
git commit →
ローカルrepo
(履歴に記録)
git push →
← git pull
リモートrepo
(GitHub等)
コミット履歴のイメージ: C1 → C2 → C3 → C4(main)
                ↘ F1 → F2(feature/xxx)

Gitの主要な概念

用語意味
リポジトリ(repo)変更履歴を管理するデータベース。ローカル/リモートに存在。
コミット(commit)変更のスナップショット。メッセージとともに履歴に記録。
ブランチ(branch)開発の分岐。mainブランチから派生して機能開発し後でマージ。
マージ(merge)ブランチを統合する操作。コンフリクト(衝突)が発生することも。
クローン(clone)リモートリポジトリのコピーをローカルに作成。
プル(pull)リモートの変更をローカルに取得して反映(fetch+merge)。
プッシュ(push)ローカルのコミットをリモートリポジトリに送信。

CI/CD(継続的インテグレーション/デリバリー)

CI(継続的インテグレーション)

コードをコミットするたびに自動でビルド・テストを実行。バグの早期発見。コード品質の維持。

CD(継続的デリバリー/デプロイ)

CIに加えてデプロイ(リリース)まで自動化。本番環境への素早い反映。アジャイルと相性良い。

DevOps:開発(Development)と運用(Operations)を統合し、CIツール・自動テスト・インフラ自動化で高速・高品質なリリースを実現する考え方。

Gitのブランチ戦略

ブランチ役割
main(master)本番リリース済みの安定コード。直接コミットは禁止が多い
develop開発の統合ブランチ。機能ブランチをここにマージ
feature/xxx新機能の開発ブランチ。developから分岐して作業
hotfix/xxx本番の緊急バグ修正用。mainから直接分岐
ブランチの目的:main(本番)ブランチを安定に保ちながら、複数の機能開発を並行して進められる。「作業が壊れても本番に影響しない」のがブランチの最大のメリット。

🎯 試験での出方

⚠️ よくある間違い

✍️ 確認クイズ

Q1. 分散型バージョン管理システムの特徴として正しいものはどれか。
✅ 正解は②。分散型VCS(Gitなど)は各開発者がリポジトリの完全なコピーをローカルに持ちます。オフラインでも作業可能で、サーバー障害に強い。中央サーバーのみは集中型VCSの特徴。
Q2. CI(継続的インテグレーション)の主な目的はどれか。
✅ 正解は②。CIはコードのコミット(またはプッシュ)のたびに自動でビルドとテストを実行し、バグを早期に発見する仕組みです。CD(継続的デリバリー)はリリースまでを自動化。
Q3. Gitで別ブランチの変更を現在のブランチに統合する操作を何というか。
✅ 正解は③。マージ(merge)はブランチの変更を統合する操作。プッシュはローカルをリモートに送信、コミットは変更をローカルリポジトリに記録する操作。
Q4. git pullとgit fetchの違いとして正しいものはどれか。
✅ 正解は②。git fetchはリモートリポジトリの変更をローカルにダウンロードするだけ(現在のブランチへのマージは行わない)。git pullはfetch+mergeを一度に行い、ローカルブランチを最新化します。
Q5. 同じファイルの同じ箇所をブランチAとブランチBでそれぞれ編集した後にマージしようとすると何が発生するか。
✅ 正解は③。同じ箇所を別々のブランチで変更するとコンフリクト(競合)が発生します。Gitはどちらを採用すべきか判断できないため、開発者が手動でコンフリクトを解決してからコミットする必要があります。

Sponsor Link