Web制作のGit管理入門：ZIP上書き事故・先祖返りを防ぐ

Web制作の現場で、こんなファイル名が増えていませんか。

「最新_20260128.zip」「最新_最終.zip」「最終_本当に最終.zip」「最終_修正反映済み.zip」

笑い話のようでいて、実際にはコストと事故の温床です。ディレクターが頑張って交通整理しても、プロジェクトが大きくなるほど限界が来ます。

この記事では、フォルダとZIPでの運用が抱える構造的な問題を整理し、Gitでどう解決できるかを、Web制作に落とし込んで丁寧に説明します。

コードを書くエンジニア向けではなく、制作を前に進める責任を持つディレクター視点で「レビュー依頼をどう仕組み化するか」まで含めて解説します。

ZIP運用が壊れる理由

ZIP運用が壊れるのは、人のミスではなく「仕組みとして壊れやすい」からです。

まずZIP/フォルダ管理で起きがちな事故を、制作現場の言葉で整理します。

上書き事故が起きる

同じファイル名で保存してしまう、共有サーバー上のファイルを誰かが上書きしてしまう、外注先から届いたZIPでローカルの差分が消える。こうした事故は、運用者が丁寧でもゼロにできません。

先祖返りが起きる

Aさんが「最新」を受け取って修正し、Bさんは古い「最新」をベースに作業し、そのまま上書き納品。結果として、すでに直っていた箇所が巻き戻ります。これが先祖返りです。大規模サイトやLP量産ほど頻発します。

差分が追えない

「どこが変わったの？」に答えるには、結局、目視で比べるしかない。ファイル比較ツールを使っても、画像やビルド成果物が混ざると人間の認知負荷が上がります。差分が追えないと、レビューの工数が雪だるま式に増えます。

誰が・いつ・なぜ変えたかが消える

ZIPは“成果物”は残しますが、“経緯”が残りません。トラブルが起きたときに「いつから崩れた？」「誰が触った？」「なぜこうした？」が辿れない。これが揉め事の原因になります。

「検品依頼」が雑になる

制作現場の本質は「確認お願いします」の連続です。ZIP運用だと、この検品依頼がSlack/メール/口頭に散って、いつ誰が何をOKしたのかが残りません。後で仕様が揺れたときに、証跡がなくて揉めます。

Gitは何を解決する仕組みか

Gitを一言でいうと「変更の履歴を、差分として残し続ける仕組み」です。フォルダの“最新版”を管理するのではなく、「いつ、どんな変更が入ったか」を積み重ねていきます。

その結果、制作現場にとって強いポイントが3つ生まれます。

いつでも戻せる（タイムマシン）

「昨日は動いていたのに…」が起きても、原因が入った地点まで戻せます。ZIPで似たことをやろうとすると、膨大なバックアップが必要になります。

誰が・いつ・なぜ変えたかが残る（証跡）

Gitは変更の単位（コミット）ごとに記録が残ります。コミットメッセージに「なぜ変えたか」を残せるので、あとから追跡できます。制作会社にとっては、バックアップ兼、証跡管理の基盤になります。

「検品依頼」を工程化できる（Pull Request）

Gitの運用とセットでよく使われるのがPull Request（PR）です。PRは英語圏だと当然のように使われますが、制作現場の言葉に翻訳すると「検品依頼（確認お願いします）の正式な提出」です。PRを起点にすると、レビューの依頼と承認が“場所”として残ります。GitHubのPRは、変更差分に対してコメントや承認ができる仕組みとして公式に説明されています。^[1]

まず押さえる用語（ディレクター向けに最小限）

Gitは用語が多くて挫折しがちなので、Web制作で最低限必要なものだけに絞ります。

リポジトリ

プロジェクトの保管庫です。サイト一式（ソースコードや設定、画像など）を置く場所だと思ってください。

コミット

変更の記録の単位です。「ここまで作業した」というスナップショットではなく、「何を変えたか」が履歴として残る点がポイントです。コミットの説明として、Gitの公式ドキュメントや定番の入門書（Pro Git）が参考になります。^[2]

ブランチ

作業の分岐です。制作現場で言うと「本番用の作業フォルダ」と「修正作業用の複製フォルダ」を安全に分けて運用できるイメージです。ブランチを使うと、途中の作業が混ざらず、レビュー単位で整理できます。

Pull Request（PR）

検品依頼です。「この変更を本番に取り込んでいいか確認してください」という提出物のページだと思ってください。PRにすると、差分、議論、承認が一箇所にまとまります。PRワークフロー自体は、Backlogなども“レビューして取り込む流れ”として分かりやすく整理しています。^[3]

Web制作でのGit運用（最小で破綻しない）

「最初から理想の運用」を目指すと失敗します。制作会社の現場でまず回る、最小の型を提示します。

役割を2つに分ける

Git運用を導入するとき、最初に決めるべきなのは責任範囲です。

コード担当（エンジニア・コーダー）がやることは「変更をコミットしてPRを出す」までで十分です。

ディレクターがやることは「PRを検品依頼として受け取り、差分と意図を確認してOK/差し戻しを返す」だけで回ります。

ディレクターがGitのコマンドを覚える必要はありません。ブラウザ上のPRを読めることがゴールです。

ブランチの名前を制作向けに寄せる

ブランチ名は制作の言葉に寄せると浸透しやすいです。

例として、LPの修正ならこういう名前が分かりやすいです。

• fix/hero-cta-spacing
• fix/form-validation-message
• update/price-table-copy
• hotfix/ios-safari-layout

「どのページの、何の修正か」がブランチ名で分かると、ディレクターの交通整理が楽になります。

PRタイトルは「検品依頼」になるように書く

PRタイトルが雑だと、ZIP運用と同じで結局迷子になります。PRを検品依頼として運用するなら、タイトルの型を統一します。

例として、LPの検品依頼タイトルはこうです。

• LP：ファーストビューCTAの余白修正（スマホ）
• LP：フォーム周りの文言差し替え＋バリデーション調整
• LP：Safariでの見出し折り返し崩れ修正

ここまで日本語で書いてOKです。ディレクターに通じれば勝ちです。

PR本文のテンプレを用意する

PR本文は「差分の説明」と「確認観点」を短く書ければ十分です。ディレクターがレビューしやすいことが最優先です。

テンプレ例です。

• 変更の目的（なぜ）
• 変更箇所（どこ）
• 影響範囲（どこまで）
• 確認してほしいポイント（何を見てほしいか）
• プレビューURL（あれば）

この型だけで、レビューが速くなり、言った言わないが減ります。

「プルリクエスト」は「検品依頼」である

PRは“開発の儀式”ではありません。制作会社にとっては、検品依頼を形式知化するための仕組みです。

ZIP運用では、検品依頼がSlackや口頭になりがちです。その結果、こういう事故が起きます。

「OKって言ったよね？」がいつの何に対してのOKか分からない。

PR運用にすると、OKはPRの承認として残ります。差し戻しもコメントとして残ります。コミュニケーションの場所が固定されるだけで、制作はかなり安定します。

GitHubのPRは、変更をレビューしてマージするための仕組みとして、差分表示やレビュー、承認などを提供することが明記されています。^[1]

ディレクターがPRで見るべきポイント（超実務）

ディレクターがPRで見るべきものは「コードの美しさ」ではありません。検品の観点です。

見た目の崩れ

LPやサイトは、わずかなCSS変更で別箇所が崩れます。PR本文に「影響範囲」が書かれているかを見て、プレビューで該当箇所と周辺を確認します。

意図通りの変更か

「直したはず」が別の仕様変更になっていないかをチェックします。ここはRevoolなどの指示ログと紐づくと強い領域です。

変更範囲が大きすぎないか

一つのPRで広範囲が変わっていると、検品が破綻します。制作現場では特に「PRを小さくする」ことが重要です。小さいPRほどレビューが速く、差し戻しも楽です。

よくあるつまずきと回避策

Git導入が失敗する原因は、ほとんどが「理想から入る」「ルールが多すぎる」「レビューが面倒で形骸化する」のどれかです。

ルールを増やしすぎない

最初から完璧なブランチ戦略や厳格なレビュー基準を作る必要はありません。まずは「ZIPをやめる」「PRで検品依頼を出す」の2点だけで十分です。

画像やデザインデータの扱いは割り切る

Gitはテキスト差分に強いので、巨大なバイナリ（PSDや巨大動画）を何でも入れると重くなります。制作物の種類によっては、Gitに入れる範囲を決める必要があります。Git LFSという選択肢もありますが、最初から必須にしない方が導入は進みます。Git LFSは公式に仕様と導入方法がまとまっています。^[4]

「PRの承認」が運用されない

PRが形だけになって「とりあえずマージ」になると、結局事故は減りません。ディレクターがPRを“検品依頼の受付窓口”として見る運用にするだけで、改善します。

GitとRevoolの親和性（ここが着地点）

Gitは「コードの履歴」を残します。誰がいつ何を変えたか、実装の証跡として強い。

ただ、制作現場で揉めるのは「指示の履歴」です。

• クライアントが何を要求したか
• どのページのどの箇所か
• いつ誰がOKしたか
• 差し戻し理由は何か
• 期限や担当はどうなっているか

Gitだけでは、これらは散りがちです。PRコメントは残りますが、画面上の指示やタスク管理、承認ログとしての運用には向き不向きがあります。

だから、役割分担が綺麗に成立します。

Gitは「実装の履歴（何を変えたか）」を担う。

Revoolは「指示と承認の履歴（なぜ変えたか、誰がOKしたか、進捗はどうか）」を担う。

この2つが揃うと、制作現場の“言った言わない”はかなり減ります。ディレクターはZIPの交通整理ではなく、品質と意思決定に時間を使えるようになります。

まとめ

ZIP運用が壊れるのは、運用者が悪いのではなく、仕組みとして事故が起きやすいからです。

Gitは「変更履歴を残す」ことで、上書き事故や先祖返りを構造的に減らし、PRを「検品依頼」として工程化できます。

ディレクターが最初にやるべきことは、Gitを完璧に理解することではありません。PRを検品依頼として受け取り、差分と意図を確認し、OK/差し戻しを返す。この役割が回るだけで、制作は一段安定します。

その上で、Gitが担う「コードの履歴」と、Revoolが担う「指示・承認の履歴」を分担すると、制作の証跡が揃い、揉め事が減っていきます。

Revoolでウェブ制作フローのレビューログを一元化してみませんか？

RevoolのChrome/Edge拡張機能

Revoolでは、画面キャプチャ撮影から修正指示付きのタスク投稿ができる拡張機能を提供しています。Revoolのアカウントなしのゲストモードで、指示コメントを書き込んだキャプチャを保存することもできます。

参考リンク