Gitと変更管理

第27講 / 全32講読了目安約50分

このページで学ぶこと

Gitが何を記録し、何を自動的には解決しないか
リポジトリ、コミット、ブランチ、Pull Request、マージの関係
小さな変更単位とレビューが、品質・進行・障害対応へ与える効果
コンフリクト、タグ、リリース、バイナリファイル等の実務上の注意
PMがブランチ戦略・承認・権限・引継ぎを設計する方法

まず全体像

Gitは、主にソースコードや設定ファイルの変更履歴を記録するバージョン管理システムです。

flowchart LR
    A[課題・変更目的] --> B[ブランチで変更]
    B --> C[コミット]
    C --> D[Pull Request]
    D --> E[レビュー・自動検査]
    E --> F[マージ]
    F --> G[検証・本番公開]
    G --> H[タグ・リリース記録]

Gitを使うと、誰が・いつ・何を・なぜ変更したかを追いやすくなります。

ただし、Gitを導入するだけで変更が安全になるわけではありません。

変更単位、コミットメッセージ、レビュー、権限、テスト、公開手順を合わせて設計します。

バージョン管理がない場合に起きること

ファイル名で版を管理すると、次のような状態になりがちです。

index_final.html
index_final2.html
index_final_fix.html
index_本番_最新.html

この方法では、

どれが本番版か
何が変わったか
誰の変更か
複数人の変更をどう統合するか
問題時にどこまで戻すか

が分かりにくくなります。

Gitでは、変更差分と履歴をリポジトリへ記録します。

リポジトリ

リポジトリは、Gitで管理するプロジェクトと変更履歴のまとまりです。

含まれる例：

HTML・CSS・JavaScript
フレームワークのソース
設定ファイル
テスト
CI/CD設定
ドキュメント
インフラ設定
CMSスキーマ定義

通常、次は直接保存しないようにします。

本番パスワード
APIシークレット
個人情報
大量の生成物
一時ファイル
端末固有設定
非公開の証明書・秘密鍵

保存対象外は.gitignore等で定義します。

一度履歴へ入れた秘密情報は、ファイルを削除しても過去履歴に残る場合があります。流出時は履歴修正だけでなく、キーの失効・再発行が必要です。

ローカルとリモート

開発者のPC上にあるリポジトリをローカルリポジトリ、GitHub等の共有先にあるものをリモートリポジトリと呼びます。

flowchart LR
    L1[担当者Aのローカル] <--> R[GitHub等のリモート]
    L2[担当者Bのローカル] <--> R
    CI[CI/CD] <--> R

変更をローカルで作り、リモートへ共有し、レビュー・自動検査・公開へつなげます。

リモートリポジトリは、単なるバックアップではありません。

変更提案
レビュー
課題との関連
権限制御
自動テスト
公開
監査履歴

の中心になります。

コミット

コミットは、変更のまとまりを履歴として記録したものです。

各コミットには一般に次が含まれます。

変更差分
作成者
日時
メッセージ
親となるコミット

flowchart LR
    C1[初期版] --> C2[ヘッダー修正]
    C2 --> C3[検索機能追加]
    C3 --> C4[エラー表示修正]

良いコミット単位

一つの目的にまとまる
レビューできる大きさ
必要なら単独で戻しやすい
テスト・ビルドが成立する
関係ない整形変更を混ぜない

「一週間分を最後に全部コミット」すると、レビュー・原因特定・切戻しが難しくなります。

コミットメッセージ

変更内容だけでなく、目的・理由が分かるようにします。

悪い例：

fix
update
修正

良い例：

問い合わせ二重送信を防ぐ
旧URLから製品詳細へ301リダイレクトを追加
CMS公開失敗時の通知先を変更

課題番号やPull Requestへ関連づけると、背景を追いやすくなります。

ブランチ

ブランチは、現在の本流から分かれて変更を進めるための履歴の分岐です。

gitGraph
    commit id: "main"
    branch feature-search
    checkout feature-search
    commit id: "検索UI"
    commit id: "API連携"
    checkout main
    commit id: "別の修正"
    merge feature-search

ブランチを使うことで、本番向けの安定した履歴と、作業中の変更を分けられます。

よく使う用途

新機能
不具合修正
緊急修正
リリース準備
検証案

ブランチを長期間分離すると、本流との差が大きくなり、統合が難しくなります。

小さく作り、早めに共有・統合する方が、問題を早く発見できます。

ブランチ戦略

ブランチの運用ルールには複数の方式があります。

短命な作業ブランチ

main等の本流から作業ブランチを作り、Pull Requestで短期間に統合します。

継続的なデリバリーやWeb制作では扱いやすい方式です。

リリースブランチ

特定リリースの安定化・修正を分離します。

複数バージョンを同時保守する製品では必要な場合がありますが、変更先・反映先が増えます。

環境とブランチを一対一にする方式

developは検証、mainは本番等、ブランチを環境へ対応させる方法です。

分かりやすい一方、検証済みコミットと本番へ入るコミットがずれる、緊急修正を複数ブランチへ反映する、といった運用課題があります。

PMが決める観点

公開頻度
並行案件数
複数バージョン保守
承認工程
緊急修正
環境数
チーム経験
CI/CD構成

方式名を採用するより、変更がどの経路で本番へ届くかを図示します。

Pull Request

Pull Requestは、あるブランチの変更を別のブランチへ取り込む提案です。

flowchart TD
    B[作業ブランチ] --> P[Pull Request]
    P --> D[差分・背景・確認方法]
    P --> R[レビュー]
    P --> C[自動チェック]
    R --> M{承認可能か}
    C --> M
    M -->|修正必要| B
    M -->|承認| G[マージ]

Pull Requestには次を記載します。

変更目的
関連課題
変更内容
対象外
画面・動画
確認方法
影響範囲
データ・設定変更
公開・切戻し注意
残課題

PM・デザイナー・クライアントがコードを読めなくても、プレビューURLと確認観点を使ってレビューへ参加できます。

レビュー

レビューには複数の観点があります。

コードレビュー

実装の正しさ
保守性
安全性
テスト
性能
既存設計との整合

デザイン・コンテンツレビュー

デザイン仕様
レスポンシブ
文言
CMS表示
アクセシビリティ
ブランド

業務レビュー

要件
データ
権限
承認
エラー
運用

レビュー担当と承認条件を明確にします。

「誰か一人がApproveしたらよい」では、必要な専門観点を満たさない場合があります。

ブランチ保護・ルールセット

重要なブランチへ直接変更できないよう、GitHub等で保護ルールを設定できます。

例：

Pull Requestを必須にする
必要な承認数
指定チームの承認
自動チェック成功を必須にする
未解決コメントを残さない
履歴を最新化してからマージ
強制push・削除を禁止
署名済みコミットを求める
特定担当だけが本番ブランチへ変更

ルールを厳しくしすぎると、緊急対応が止まる場合があります。

例外権限、利用条件、事後レビューを決めます。

マージ

マージは、分岐した変更履歴を統合することです。

GitHub等では、主に次の方法があります。

マージコミット

作業ブランチの履歴を保ち、統合した記録を追加します。

スカッシュマージ

Pull Request内の複数コミットを一つにまとめます。

リベースマージ

コミットを本流の先へ並べ直し、直線的な履歴にします。

どの方式が絶対に正しいわけではありません。

履歴の読みやすさ
コミット品質
切戻し
チーム習熟
監査要件

で選びます。

PMはコマンド詳細より、「Pull Request単位で何が本番へ入ったか追跡できるか」を確認します。

コンフリクト

同じ箇所へ異なる変更を行うと、Gitが自動統合できないことがあります。これがコンフリクトです。

flowchart TD
    A[共通の元版] --> B[担当者Aが文言変更]
    A --> C[担当者Bが構造変更]
    B --> D{統合}
    C --> D
    D -->|自動判断不可| E[人間が正しい内容を決定]

コンフリクトはGitの故障ではありません。

どちらの変更を残し、どう組み合わせるか、業務・デザイン・技術上の判断が必要です。

減らす方法

作業範囲を分ける
小さく早く統合する
大規模な一括整形を別Pull Requestにする
CMS・設定・共通ファイルの変更を共有する
長期間ブランチを放置しない

コンフリクト解消後は、単にビルドできるだけでなく、両方の要件が残っているかテストします。

タグとリリース

タグは、特定のコミットへ名前を付ける仕組みです。

例：

v1.0.0
release-2026-07-15
before-renewal

リリース機能では、タグに加えて変更内容、成果物、注意事項等を記録できます。

flowchart LR
    C1[コミット] --> C2[コミット]
    C2 --> T[タグ v1.0.0]
    T --> R[リリースノート]

タグを付けると、

本番へ出した版
障害発生時の版
切戻し先
納品版

を特定しやすくなります。

ただし、データベース・CMS・外部サービスの状態はGitタグだけでは戻りません。

セマンティックバージョニング

ソフトウェアでは、MAJOR.MINOR.PATCHのような番号を使うことがあります。

MAJOR：互換性のない変更
MINOR：互換性を保った機能追加
PATCH：互換性を保った修正

一般公開するライブラリやAPIでは有用です。

Webサイトの日常更新では、日付・リリース番号・Pull Requestの方が運用に合う場合もあります。

何をバージョンとするかを決めます。

Gitが管理しにくいもの

Gitはテキスト差分に強い一方、次は注意が必要です。

Photoshop・PowerPoint等のバイナリ
大容量動画
大量画像
データベース
CMSコンテンツ
個人情報
生成済みファイル
クラウド管理画面だけの設定

大容量ファイルはGit LFSや別ストレージを検討します。

Figma・CMS・クラウド等の変更履歴は、それぞれの仕組みと引継ぎ資料で管理します。

「Gitにないもの」を構成図・台帳で明確にします。

GitとCMS・データベース

CMSコンテンツ

通常、記事本文・画像等はCMS側に保存され、Gitのコミットには含まれません。

フロントの変更を戻しても、CMS更新は戻りません。

CMSスキーマ

コンテンツタイプ・項目等をAPIや設定ファイルとして管理できる場合、Gitへ記録できます。

管理画面だけで変更する場合、変更履歴・環境差・引継ぎを別途管理します。

データベース

構造変更用のマイグレーションファイルはGitへ入れられますが、実データは別管理です。

コードを戻しても、DB構造を戻せない場合があります。

リリース・ロールバック計画でセットにします。

Gitと課題管理

Gitの変更をBacklog、GitHub Issues、Jira等の課題へ関連づけます。

flowchart LR
    I[課題・要件] --> B[ブランチ]
    B --> C[コミット]
    C --> P[Pull Request]
    P --> R[リリース]
    R --> I

これにより、

なぜ変更したか
誰が承認したか
どの版で公開したか
どのテストをしたか

を追跡できます。

チャットだけで仕様変更を確定すると、後から履歴を追えません。

決定事項を課題・Pull Request・仕様書へ残します。

緊急修正

本番障害では、通常より短い経路で修正したい場合があります。

事前に決めること

緊急と判断する条件
誰が承認するか
直接pushを許可するか
最低限必要なテスト
本番反映方法
切戻し
通常ブランチへの反映
事後レビュー
インシデント記録

緊急時でも、変更履歴・実施者・対象版を残します。

直接本番だけ直し、Gitへ反映し忘れると、次回公開で修正が消えます。

リポジトリの所有と権限

クライアント案件では、リポジトリを誰の組織へ置くかを決めます。

確認事項

所有組織
契約終了後のアクセス
管理者
外部協力会社
招待・退場
private/public
バックアップ
GitHub Actionsの課金
シークレット
リポジトリ移管
監査ログ
アーカイブ・削除

制作会社の担当者個人アカウントだけが管理者、という状態を避けます。

クライアント名義のGitHub組織を使う場合、権限付与・サポート・請求を確認します。

実案件ではどう考えるか

コーポレートサイト

ページ・コンポーネント変更
CMSスキーマ
リダイレクト
SEO設定
CI/CD
インフラ設定

をGitで管理します。

CMS本文・画像、DNS管理画面、外部フォーム設定等は別管理であることを一覧化します。

複数案件を一つのリポジトリで管理

共通部品を再利用しやすい一方、

変更が複数案件へ影響
権限分離
公開単位
CI/CD時間
緊急修正
契約終了時の引渡し

を設計します。

一つのリポジトリか案件別かは、技術だけでなく運用・セキュリティ・契約で判断します。

外部ベンダーとの共同開発

CODEOWNERS等でレビュー担当を指定
ブランチ保護
Pull Requestテンプレート
必須チェック
外部メンバーの期限付き権限
秘密情報へのアクセス制限

を用意します。

PMチェックリスト

よくある誤解・失敗

「Gitに入っているのでバックアップは万全」

リモートリポジトリ自体の削除・侵害、CMS・DB・クラウド設定等は別問題です。所有・復旧・他データを確認します。

「ブランチを細かく分けるほど安全」

長期間・多数のブランチは差分とコンフリクトを増やします。必要な分離と早い統合のバランスが必要です。

「Pull Requestはエンジニアだけが見るもの」

プレビュー、変更目的、業務確認を使えば、PM・デザイナー・クライアントもレビューできます。

「マージできたので変更は正しい」

Gitが統合できることと、要件・表示・データが正しいことは別です。自動・手動テストが必要です。

「以前のコミットへ戻せば完全にロールバックできる」

CMS、DB、外部API、DNS、キャッシュ、送信済みデータ等はGitだけでは戻りません。

理解度チェック

Q1. コミットとPull Requestの違いは何ですか。

回答と解説

コミットは変更のまとまりを履歴へ記録したものです。Pull Requestは複数のコミットを含むブランチの変更を、別ブランチへ統合する提案・レビューの場です。

Q2. ブランチを長期間分離する主な問題は何ですか。

回答と解説

本流との差が大きくなり、コンフリクト、統合時の大規模差分、要件ずれ、テスト範囲の増加が起きやすくなります。

Q3. ブランチ保護で設定できることの例を挙げてください。

回答と解説

Pull Request、承認、必須ステータスチェック、直接push・強制push・削除の制限等です。GitHubのプラン・設定で利用可能範囲を確認します。

Q4. Gitでソースを戻しても、元に戻らない可能性があるものは何ですか。

回答と解説

CMSコンテンツ、データベース、外部サービスの状態、DNS、クラウド設定、送信済みフォーム・決済、キャッシュ等です。

Q5. 緊急修正で最低限残すべき記録は何ですか。

回答と解説

問題・影響、変更内容、実施者、承認者、対象コミット・版、確認結果、切戻し、通常ブランチへの反映、事後レビューです。

参考資料

MIXI「Git 研修 Basic【MIXI 25新卒技術研修】」
https://speakerdeck.com/mixi_engineers/2025_new_grad_training_git_basic
リポジトリ、コミット、ブランチ等の基礎を体系的に学ぶ参考資料。
MIXI 2025BeginnerTrainingGit
https://github.com/mixigroup/2025BeginnerTrainingGit
上記研修の演習用公式リポジトリ。
GitHub Docs「About protected branches」
https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
Pull Request、レビュー、ステータスチェック等を重要ブランチへ要求する公式機能の説明。
GitHub Docs「About pull requests」
https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
Git Reference
https://git-scm.com/docs
Git本体の公式リファレンス。