この記事の要点

バージョン管理システム (VCS) はファイルの変更履歴を時系列で記録し、過去への復帰・並行開発・コードレビューを可能にする仕組み 分散型 (Git, Mercurial): 全員が完全な履歴を持つ。オフライン作業可能。現在の主流 集中型 (SVN, CVS): 中央サーバ 1 つに履歴がある。シンプルだがオフライン作業不可 主要ホスティング: GitHub (Microsoft)、GitLab、Bitbucket (Atlassian)、Gitea / Forgejo (セルフホスト OSS)、AWS CodeCommit 運用フロー: Git Flow (機能/リリース/hotfix ブランチ)、GitHub Flow (main + 機能ブランチ)、Trunk Based (短命ブランチ + CI)

バージョン管理システムとは

バージョン管理システム (Version Control System, VCS) は、ファイル群の変更履歴を時系列で記録し、いつでも過去の状態に戻せるようにするツールです。ソースコードの管理が主用途ですが、ドキュメント・設定ファイル・小さなバイナリにも適用できます。

VCS を使う主な目的:

• 変更の履歴を残す — 誰がいつ何を変えたか追跡
• 過去のバージョンに戻す — バグ混入箇所の特定 (git bisect)
• 並行開発 — ブランチで複数人/複数機能を同時に進める
• コードレビュー — Pull Request / Merge Request で変更を確認
• バックアップ — リモートリポジトリが事実上のバックアップ

集中型 vs 分散型

観点	集中型 (SVN, CVS)	分散型 (Git, Mercurial)
リポジトリ	中央サーバ 1 つ	各開発者がフルコピーを保有
コミット	サーバ接続必須	ローカルでコミット可
オフライン作業	不可	可能
ブランチ	重い (ディレクトリコピー)	軽量・高速
マージ	履歴管理が複雑	三方向マージで堅牢
サーバ障害	全停止	各自のローカルから復元可
学習コスト	低	中 (ブランチ・rebase 等)

主要 VCS の歴史

VCS	登場年	状態	備考
SCCS	1972	歴史的	最初期
RCS	1982	歴史的	ファイル単位管理
CVS	1990	レガシー	長年の標準だった
Subversion (SVN)	2000	現役 (縮小)	CVS の改良型
Mercurial (hg)	2005	現役 (縮小)	Python 製分散型
Git	2005	事実上の標準	Linus Torvalds 作
Bazaar (bzr)	2005	ほぼ廃止	Canonical 製
Perforce	1995	現役	ゲーム業界・大規模バイナリ

Git の特徴

• 分散型: 完全な履歴を全員が持つ
• コミットグラフ: 各コミットは親コミットへの参照を持つ DAG (有向非巡回グラフ)
• SHA-1 (現在 SHA-256 移行中) ハッシュでコミット識別: a3f5d2c...
• ブランチが軽量: ポインタを増やすだけ、コストほぼゼロ
• ステージング領域 (index): コミット前にどの変更を含めるか選択可能
• 3 つの状態: Working Tree → Index (ステージ) → Repository (コミット済)

# Git の基本フロー
git init                              # リポジトリ初期化
git clone https://github.com/user/repo.git

git status                            # 現状確認
git add file.txt                      # ステージング
git commit -m "Add file"              # コミット
git log --oneline --graph             # 履歴表示

# ブランチ
git branch feature/login              # 作成
git checkout feature/login            # 切替 (Git 2.23+ は git switch 推奨)
git switch -c feature/login           # 作成+切替 (新形式)

# マージ
git checkout main
git merge feature/login

# リモート連携
git remote add origin https://github.com/user/repo.git
git push -u origin main
git pull origin main
git fetch origin

SVN の特徴と基本操作

# チェックアウト
svn checkout https://svn.example.com/repo/trunk myproject

# 状態確認
svn status
svn diff

# 追加・削除
svn add newfile.txt
svn delete oldfile.txt

# コミット (常にサーバへ)
svn commit -m "Add new file"

# 更新
svn update

# ブランチ (ディレクトリコピー)
svn copy ^/trunk ^/branches/feature-login -m "Create branch"
svn switch ^/branches/feature-login

# マージ
svn merge ^/branches/feature-login

主要ホスティングサービス

サービス	運営	特徴
GitHub	Microsoft	世界最大。OSS の中心地。Actions (CI/CD)、Copilot
GitLab	GitLab Inc.	セルフホスト可。CI/CD・Wiki・Issue が統合
Bitbucket	Atlassian	Jira / Confluence と連携。中小規模に強い
Azure Repos	Microsoft	Azure DevOps 内。エンタープライズ向け
AWS CodeCommit	AWS	AWS 内完結。IAM 認証
Gitea / Forgejo	OSS	軽量セルフホスト。GitHub 風 UI
SourceHut	Drew DeVault	ミニマル・メーリングリスト型

運用フロー (ブランチ戦略)

Git Flow

2010 年 Vincent Driessen 提唱の老舗フロー。複数ブランチで明確に役割分担します。

main          : 本番リリース版。タグ付き
develop       : 開発統合
feature/*     : 機能開発 (develop から分岐 → develop にマージ)
release/*     : リリース準備 (develop から分岐 → main + develop にマージ)
hotfix/*      : 緊急修正 (main から分岐 → main + develop にマージ)

長所: 明確な役割分担、リリース計画が立てやすい
短所: ブランチが多く CI/CD と相性が悪い、複雑

GitHub Flow

GitHub 社が推奨するシンプルフロー。常時リリース可能なプロダクトに向く。

main          : 常時デプロイ可能
feature/*     : 機能ブランチ (main から分岐)
                 → PR を出してレビュー
                 → CI 通過 + 承認後 main にマージ
                 → 即デプロイ

Trunk Based Development

Google / Facebook 採用。短命ブランチ (24 時間以内) + 強力な CI でメインラインを常時グリーンに保つ。Feature Flag を併用してリリース未完成機能を隠す。

CI/CD 連携

サービス	連携先
GitHub Actions	GitHub 統合 (yaml で定義)
GitLab CI/CD	GitLab 統合 (.gitlab-ci.yml)
Jenkins	OSS の老舗。プラグインで何でも
CircleCI	クラウド CI。GitHub 連携
Bitbucket Pipelines	Bitbucket 統合
AWS CodeBuild / CodePipeline	AWS マネージド CI/CD

Git LFS (Large File Storage)

Git は大きなバイナリファイル (動画、デザインデータ、機械学習モデル) が苦手です。Git LFS 拡張を使うと、リポジトリには小さなポインタだけ置き、実体は別ストレージに保管できます。

# インストール後、対象拡張子を指定
git lfs install
git lfs track "*.psd"
git lfs track "*.mp4"
git add .gitattributes

# 通常通り add / commit
git add design.psd
git commit -m "Add design file"
git push

SVN から Git への移行

# git svn を使った移行 (履歴を保持)
git svn clone https://svn.example.com/repo --stdlayout \
    --authors-file=authors.txt \
    myproject-git

# authors.txt の例
# svn_user = Full Name <email@example.com>

cd myproject-git

# 新しい Git リモートへ push
git remote add origin https://github.com/user/myproject.git
git push -u origin main --tags

FAQ

Q: いまから新規プロジェクトを始める。SVN と Git どちらを選ぶ？
A: Git 一択です。OSS / 商用問わず事実上の標準で、CI/CD・コードレビュー・周辺ツールすべて Git 前提で発展しています。

Q: チーム全員が Git 初心者。何から教える？
A: clone → add → commit → push → pull の基本サイクルと、branch → PR の流れだけで実用可能です。rebase や cherry-pick は後回しで OK。

Q: GitHub と GitLab、社内で選ぶならどっち？
A: クラウド完結なら GitHub、セルフホスト要件 (機密度・社内ネットワーク制約) なら GitLab。社内 GitLab + GitHub Public で公開、というハイブリッドも一般的。