01-03_GitHub

出典: 制作部署マニュアル GitHub（自動ミラー・正本は /Users/oogushiyuuki/manual-terasu）

まず「Git」と「GitHub」がそもそも何かを理解する

GitHubと聞いて身構える必要はない。やってることは、普段あなたがGoogleドキュメントやスマホのゲームでやってることとほぼ同じ。「履歴を残しながら作業して、必要なら過去に戻る」だけ。まずはイメージから掴む。

Gitとは ＝ 作業の「セーブポイント」を作る仕組み

ゲームをプレイする時、ボス戦の前にセーブするよね。負けてもそのセーブ地点からやり直せる。Gitはこれと同じで、HP制作のファイルに対して「ここまでの状態」をセーブ（記録）していく仕組み。

Git ＝ ファイルの変更履歴を、セーブポイントとして好きなだけ残せるツール。

• 「トップページのデザインを直す前」の状態をセーブ
• 直した後、もし気に入らなければワンタッチで直す前に戻せる
• いつ・誰が・どこを変えたかが、全部記録に残る

普通のフォルダだと「上書き保存」したら前の状態は消える。Gitなら消えない。これが一番の違い。

GitHubとは ＝ そのセーブデータを置く「クラウド倉庫」＋共有の場

Gitが「セーブする仕組み」なら、GitHub（ギットハブ）は、そのセーブデータをインターネット上に保管しておく場所。Googleドライブの「コード版」だと思えばいい。

	例え	役割
Git	ゲームのセーブ機能	自分のPCの中で履歴を記録する仕組み
GitHub	クラウドのセーブ倉庫＋共有スペース	履歴をネット上に保管し、複数人で共有・共同編集する場所

つまり Git（仕組み）で記録 → GitHub（場所）に保管・共有 という関係。「履歴付きのGoogleドキュメントを、コード用に超強力にしたもの」と覚えておけばOK。

Git ＝ 履歴を残すツール（自分のPCの中）
GitHub ＝ その履歴を置くクラウド倉庫（みんなで共有）

---

なぜTERASUがGitHubを使うのか

「セーブできて便利」だけなら個人の話。TERASUが全クライアントHPの制作・運用にGitHubを使うのには、ビジネス上の明確な理由が4つある。

#	理由	中身
	変更履歴が全部残る	いつ・誰が・どこを変えたか完全記録。「先週の状態に戻して」が一瞬。ミスっても巻き戻せるから安心して触れる
	push＝自動でHPが更新される	GitHubにアップ（push）すると、Cloudflare Pagesが検知して自動でHPを公開。FTPでファイルをアップロード…みたいな手作業デプロイが一切いらない
	複数人で壊さず編集できる	同じHPを複数人で同時に触っても、ブランチ（後述）で作業を分ければ衝突しない。誰かの修正が別の人の修正を消す事故が起きない
	プレビュー共有が一瞬	「この状態どうですか？」を専用URLでサッと共有。相手はリンクを開くだけで確認できる

特に大きいのが 。「ファイルを直してGitHubに上げる」だけで、約30〜40秒後には本番HPが更新される。この自動化があるから、TERASUは月額1万で「修正無制限・運用サポート」を回せる。手作業デプロイしてたら人件費で赤字になる。

つまりGitHubは、TERASUのサービスを成り立たせている裏側のエンジン。ここを理解すると仕事の流れが全部繋がる。

---

基本用語をひとつずつ（ここが一番大事）

GitHubは横文字の用語が多くて、それだけで拒否反応が出がち。でも一個ずつ「何か・いつ使うか」を例えで押さえれば、全部当たり前のことを言ってるだけ。焦らず順番に。

リポジトリ（repository / 略してrepo・レポ）

ひとつのHP（プロジェクト）の、全ファイル＋全履歴をまとめて入れておく「箱」。

• 例えるなら「ひとつの案件専用のフォルダ」。ただし中に履歴も全部入ってる
• TERASUではクライアント1社につき1リポジトリを作る（例：A社のHP用リポジトリ、B社のHP用リポジトリ）
• HTMLもCSSも画像も、そのHPに必要なもの全部がこの箱に入る

「リポジトリ作って」＝「この案件専用の箱をGitHub上に用意して」という意味。

コミット（commit）

「ここまでの変更内容に名前を付けてセーブする」操作。ゲームのセーブそのもの。

• ファイルを直したら、commitして「トップページの見出しを修正」のように一言メモを付けて記録する
• このメモがあるから、後で履歴を見たとき「いつ何をやったか」が一目で分かる
• 1コミット＝1セーブポイント。こまめにコミットするほど、細かく巻き戻せる

いつ使う？ → キリのいい変更が終わるたび。「ロゴを差し替えた」「料金表を追加した」など、意味のあるまとまりごとにコミットする。

プッシュ（push）

自分のPCで作ったコミット（セーブ）を、GitHub（クラウド倉庫）にアップロードする操作。

• コミットしただけでは、まだ自分のPCの中にあるだけ。pushして初めてGitHubに上がる
• TERASUではこのpushが超重要。pushすると、それを合図にCloudflareが自動でHPを公開してくれるから
• 「ネットに反映する」＝push、と覚える

いつ使う？ → コミットして、その内容をネットに反映したい時。push＝「アップロードして全体に共有」。

プル（pull）

GitHub上にある最新の状態を、自分のPCに取り込む（ダウンロードする）操作。pushの逆。

• 他のメンバーが先に修正してpushしていたら、その変更をpullで自分のPCに取り込む
• 作業を始める前に必ずpullするのが鉄則。これを忘れると古い状態の上で作業してしまい、後で衝突（コンフリクト）の原因になる

いつ使う？ → 作業を始める前。「最新を取ってくる」＝pull。

クローン（clone）

GitHub上のリポジトリ（箱）を、まるごと自分のPCに初めてコピーしてくる操作。

• 既存の案件を触ることになったら、まずcloneしてリポジトリを自分のPCに落としてくる
• 1回やればOK。2回目以降の更新取り込みはpullを使う
• 「最初のダウンロード」＝clone、「2回目以降の更新」＝pull、という使い分け

いつ使う？ → その案件を初めて自分のPCで触る時の、最初の1回。

ブランチ（branch）

本線を傷つけずに、作業用の「枝分かれ」を作る仕組み。GitHubで一番つまずきやすいけど、一番大事。

木の幹（みき）から枝が伸びるイメージ。幹＝公開中の本番、枝＝作業中のコピー。

• 枝（作業用ブランチ）の上でどれだけ大胆に直しても、幹（本番）には一切影響しない
• 直し終わって「これでOK」となったら、枝の内容を幹に合流（マージ）させる
• だから安心して試せる。失敗しても枝を捨てればいいだけ

TERASUでは「main」と「preview」という2本のブランチを使う（次で詳しく説明）。

マージ（merge）

枝（ブランチ）で作った変更を、別のブランチに合流・統合する操作。

• previewブランチで作った修正を、mainブランチにマージ＝合流させると、本番HPに反映される
• 「作業した内容を本線に取り込む」のがマージ

いつ使う？ → 作業が完成して、本番に反映する時。TERASUでは「preview → mainにマージ＝公式ドメインで本番公開」。

プルリクエスト（Pull Request / 略してPR）

「このブランチの変更を、こっちのブランチに取り込んでいいですか？」というお伺い＆レビュー依頼。

• いきなりマージするんじゃなく、「この変更どうですか、問題なければ取り込みます」と一度確認を挟む仕組み
• PRの画面では「どこをどう変えたか」が色分けで全部見える。だからレビューしやすい
• チームで「勝手に本番へ反映」を防ぐための、安全装置でもある

いつ使う？ → 変更を本番（main）に入れる前に、内容を確認・承認してもらいたい時。

main ブランチ と preview ブランチ（TERASUの2本柱）

TERASUの運用で必ず出てくる2本。これだけは絶対に覚える。

ブランチ	役割	言い換えると
main	本番。公式ドメインで公開される、お客さんが実際に見るHP	「お客さんに見せている完成品」
preview	作業＆確認用。修正をここに上げて、専用URLで内輪チェックする	「公開前の試着室」

鉄則：いきなりmainを触らない。必ずpreviewで作って確認 → OKが出てからmainにマージして本番公開。これで「ミスがそのままお客さんに出る事故」を構造的に防ぐ。

---

TERASUでの実際の流れ（これが仕事の核心）

用語が分かったところで、TERASUで実際にどう動くかを時系列で見る。HP制作フロー（hp-flow）の中にGitHubが組み込まれていて、流れに乗るだけで自動デプロイの恩恵が受けられる。

hp-flowのStep5で、案件用のGitHubリポジトリを作る

クライアントの会社名が確定するStep5のタイミングで、その案件専用のGitHubリポジトリ（箱）を作成する。ここから、そのHP専用のGitHub運用が始まる。

専用のプレビューURLが発行される

リポジトリを作ると、その案件専用のプレビューURLが自動で割り当てられる。形は決まっていて：

preview.client-{案件名}.pages.dev

例えば案件名が tanaka なら preview.client-tanaka.pages.dev のようなURL。このURLが「公開前の確認専用ページ」になる。

previewブランチにpushするたび、プレビューが自動更新される

ここが気持ちいいポイント。修正したらpreviewブランチにpushする。すると：

• pushするたびに、上のプレビューURLが自動で最新の状態に更新される
• commitがそのまま履歴（バージョン）になるので、別途バックアップ（tar.gz）を取る必要がない。GitHubが全部覚えてくれている
• もし修正をなかったことにしたい時は、git revertコマンドでワンタッチで前の状態に巻き戻せる

つまり「直す → pushする → プレビューURLを見る」のループを回すだけ。ファイルを手でアップロードしたり、バックアップを手動で取ったりする作業は一切ない。

大串／担当がプレビューURLで確認してOKを出す

プレビューURLを大串や担当に共有し、実際の見た目を確認してもらう。リンクを開くだけなので、相手の手間もほぼゼロ。修正の要望があれば に戻ってまた直す。

preview を main にマージ＝公式ドメインで本番公開

OKが出たら、previewブランチの内容をmainブランチにマージする。この瞬間、変更が本番に反映され、公式ドメインでHPが公開（更新）される。

流れまとめ：リポジトリ作成 → previewにpush（プレビュー自動更新）→ 確認OK → mainにマージ（本番公開）。この一本道を覚えれば、TERASUのHP運用は回せる。

★前提：トークンが登録済みだから「人手ゼロ」で自動デプロイされる

「なんでpushしただけで勝手に公開されるの？」の答えがこれ。

TERASUのGitHub組織（scale-group-jp）には、Cloudflareと連携するための鍵（CLOUDFLARE_API_TOKEN）が組織全体の設定（org secret）として1回だけ登録済み。だから：

• 新しい案件でリポジトリを作っても、毎回その鍵を設定し直す必要がない
• 鍵が効いているから、pushを合図にCloudflareが自動でビルド＆公開してくれる
• 2案件目以降は、人が手を動かす設定作業ゼロで自動デプロイが効く

この「最初に1回だけ鍵を登録 → 以降は全案件自動」の仕組みが、TERASUがHP制作を量産できる土台になっている。あなたは流れに乗るだけでいい。

---

Cloudflare Pagesとの連携の仕組み（裏で何が起きているか）

「pushしたら30〜40秒で公開」の裏側を、図解的に文章で追う。仕組みが分かると、トラブル時に「今どの段階で止まってるか」が分かるようになる。

①あなたがファイルを修正
        ↓
②git commit（変更にメモを付けてセーブ）
        ↓
③git push（GitHubのクラウド倉庫にアップロード）
        ↓
④Cloudflare Pagesが「お、pushされたな」と自動で検知
        ↓
⑤Cloudflareが自動でビルド＆デプロイ（公開準備）… 約30〜40秒
        ↓
⑥プレビューURL or 公式ドメインに反映完了！

ポイントを言葉で押さえる：

段階	何が起きているか
③ push	あなたの仕事はここまで。あとは全自動
④ 検知	Cloudflareが常にGitHubを見張っていて、pushを自動でキャッチ
⑤ ビルド	HTMLやCSSを「公開できる形」に組み立て直す。ここが約30〜40秒かかる
⑥ 反映	previewへのpushならプレビューURL、mainへのマージなら公式ドメインに反映

push後すぐにURLを開いても、まだ古いままのことがある。⑤のビルドに30〜40秒かかるから。少し待ってから（または一度リロードして）確認するのがコツ。「反映されてない！」の8割はこの待ち不足。

---

最低限の操作（コマンド付き）

ここからは実際に手を動かす部分。全部覚えなくていい。下の数個をコピペで使えれば、TERASUの仕事は回る。コマンドは黒い画面（ターミナル）に打ち込む。最初は意味が分からなくてもOK、まずは「この操作の時はこのコマンド」と紐付けるだけ。

黒い画面（ターミナル）が苦手な人は、GitHub Desktopという無料の専用アプリを使えば、ボタンクリックだけで同じこと（commit / push / pull / ブランチ切替）ができる。コマンドが怖い間はGUIでOK。慣れてきたらコマンドに移行すると速い。

リポジトリを自分のPCにコピーする（clone）

既存の案件を初めて触る時の、最初の1回だけ。GitHubのリポジトリページにある緑の「Code」ボタンからURLをコピーして使う。

git clone https://github.com/scale-group-jp/client-tanaka.git

これでclient-tanakaというフォルダがPCにでき、中に全ファイルが入る。

変更を記録してネットに反映する（add → commit → push）

一番よく使う3点セット。この3つの順番がワンセット。

# ① 変更したファイルを「記録対象」に全部入れる（. は「全部」の意味）
git add .

# ② メモを付けてセーブ（-m の後の " " 内に何をやったか書く）
git commit -m "トップページの見出しと料金表を修正"

# ③ GitHubにアップロード（＝Cloudflareが自動公開してくれる）
git push

コミットのメモ（-mの中身）は「何をやったか」が後で分かる一言を書く。「修正」だけだと後で見て分からない。「ファーストビューの画像を差し替え」のように具体的に。

作業用のブランチを切る／本番に合流させる（branch → merge）

previewブランチに移動して作業し、完成したらmainに合流させる流れ。

# previewブランチを作って、そこに移動する（-b は「作って移動」）
git checkout -b preview

# （ここでファイルを直して、上の add → commit → push を行う）

# 確認OK後：mainブランチに移動して、previewの内容を合流（マージ）させる
git checkout main
git merge preview
git push

実際のTERASU運用では、mainへの合流はGitHub上の画面でプルリクエスト（PR）を作って行うことも多い。色分けで変更内容を確認しながら、ボタンひとつでマージできる。コマンドが不安なら、合流はPRでやると安全。

最新を取り込む（pull）

作業を始める前に、他の人の最新の変更を取り込む。毎回作業前にやる癖をつける。

git pull

---

よくあるトラブルと対処

未経験者が必ず一度はハマるポイントと、その抜け方をまとめる。慌てない。Gitは履歴が残るから、大抵のことは元に戻せる。

pushできない（rejected と出る）

原因：自分がpushしようとする前に、他の人が先にpushしていて、GitHub上の方が新しい状態。Gitが「古い状態で上書きしないで」と止めてくれている。

対処：まずpullで最新を取り込んでから、もう一度pushする。

git pull
git push

教訓：作業前のpullを習慣にすれば、これはほぼ起きない。

コンフリクト（conflict）が起きた

原因：自分と他の人が、同じファイルの同じ行を別々に直した。Gitが「どっちを採用していいか分からない」と判断を仰いでいる状態。エラーではなく、ただの「確認待ち」。

対処：

• 該当ファイルを開くと、<<<<<<< ======= >>>>>>> という記号で両方の変更が並べて表示される
• どちらを残すか（または両方を活かすか）を決めて、その記号ごと不要な方を消して、正しい形に手で整える
• 整えたら、いつも通りadd → commit → pushする
• 自信がなければ自分で解決せず、大串や開発担当に画面を見せて相談する。下手にいじって他人の修正を消す方が事故になる

間違えてpushしてしまった／公開した状態を戻したい

原因：ミスした修正をpushしてしまい、プレビューや本番に反映されてしまった。

対処：git revertで「その変更を打ち消す新しいコミット」を作る。履歴を消すのではなく、「取り消し」を上から重ねるイメージなので安全。

# 直前のコミットを打ち消す（HEAD = 一番新しいコミット）
git revert HEAD
git push

これでpushすれば、Cloudflareが自動で「打ち消した後の状態」に再公開してくれる。tar.gzバックアップを探さなくても、コミット履歴から巻き戻せるのがGitHub運用の強み。

「どのコミットに戻せばいいか分からない」時は、GitHubのリポジトリ画面の「Commits（履歴）」を開けば、過去のセーブポイントが全部一覧で見える。怖がらず履歴を見にいく。

そもそも操作が不安で手が止まる

• 読むだけ（clone / pull / 履歴を見る）は何も壊れない。怖いのは push と merge だけ。まずは読む操作で慣れる
• 本番（main）に直接触らず、必ずpreviewで試す。previewはいくら失敗しても本番に影響しない
• 詰まったら抱え込まず、大串や開発担当に「今こうなってます」と画面を見せて聞く。GitHubは履歴が残るので、後からでも復旧できる

---

まとめ・チェックリスト

結論：GitHubは「履歴付きのセーブ機能つきクラウド倉庫」。難しそうな用語も、一個ずつ見れば日常の作業と同じこと。TERASUでは「previewにpush → 確認 → mainにマージ」の一本道さえ押さえれば、自動デプロイの恩恵を受けながらHPを安全に作って公開できる。

• [ ] Git＝履歴を残すツール、GitHub＝それを置くクラウド倉庫、の違いが説明できる
• [ ] リポジトリ／コミット／push／pull／clone／ブランチ／マージ／PR の意味が「例えで」言える
• [ ] mainは本番、previewは確認用で、いきなりmainを触らないと理解した
• [ ] TERASUの流れ「リポジトリ作成 → previewにpush → 確認OK → mainにマージで本番公開」が言える
• [ ] push後は30〜40秒待ってからURLを確認すると分かっている
• [ ] git add . → git commit -m "..." → git push の3点セットが使える
• [ ] 作業前にgit pullする癖がついた
• [ ] pushできない時はpullしてからpush、と覚えた
• [ ] 間違えたらgit revertで巻き戻せる（tar.gz不要）と知っている
• [ ] 怖い操作（push・merge）の前と、コンフリクト時は抱え込まず相談する意識がある

最初は誰でも横文字に圧倒される。でも実際に使うのは数個のコマンドだけ。「直す → push → プレビューで確認」を一度自分の手で回せば、もう怖くない。まずはpreviewで気軽に試すところから始めよう。