1. はじめに：なぜサイトをGit管理することにしたのか
このサイトは複数の端末・複数の作業セッションから並行して更新することがあります。ある時、片方の端末で直したばかりの内容が、もう片方の端末が「少し前の古い状態」のファイルをそのままアップロードしてしまったことで、静かに消えてしまう事故が実際に起きました。
実際に起きた事故
A端末で修正 → 保存直後に、B端末が(A端末の修正を知らないまま)自分の手元にあった古いコピーをアップロード → A端末の修正が跡形もなく上書きされて消える。単純にファイルをアップロードするだけの運用では、「今、他の誰か（何か）が新しく直したばかりかどうか」を知る手段がありませんでした。
これを防ぐために導入したのが、プログラマーの世界で標準的に使われているバージョン管理システム「Git」と、そのクラウド版である「GitHub」です。
2. Git／GitHubとは？（基礎知識の整理）
まず言葉の意味から整理します。
| 用語 | 身近な例え | 役割 |
|---|---|---|
| Git | ゲームの「セーブデータ」を記録する仕組みそのもの | ファイルの変更履歴を、手元のPC（サーバー）の中に記録するソフトウェア。いつでも過去のセーブポイントに戻せる。 |
| GitHub | そのセーブデータを預けておく「オンライン倉庫」 | Gitの履歴をインターネット上に保管・共有できるサービス。複数の場所からアクセスできる「共通の正本」を置いておける。 |
| リポジトリ（Repository） | 1つのセーブデータの入れ物（フォルダ全体） | このサイトの場合、/var/www/htmlフォルダ全体が1つのリポジトリに対応する。 |
| コミット（Commit） | 「ここまで進んだのでセーブ」の操作 | 変更内容に短いメモ（コミットメッセージ）を添えて記録する行為。 |
| push／pull | セーブデータの「アップロード／ダウンロード」 | push＝手元の記録をGitHubへ送る。pull＝GitHub上の最新を手元に取り込む。 |
■ 全体像（役割分担）
[ 端末A（PCまたは作業セッション） ] [ 端末B（別のPCまたは作業セッション） ]
│ git push / pull │ git push / pull
▼ ▼
┌─────────────────────────────┐
│ GitHub（非公開リポジトリ） │ ← 「共通の正本」を1箇所に集約
│ 変更履歴をすべて記録 │
└─────────────────────────────┘
│ git pull
▼
┌─────────────────────────────┐
│ 自宅サーバー（Rocky Linux 9） │
│ /var/www/html（Webサイト実体）│
└─────────────────────────────┘ポイントは、「誰か1人が最後にpushした内容」がGitHub上の"正本"として一元管理されることです。他の端末は作業を始める前に必ずGitHubから最新版を取り込む（pull）ので、「知らないうちに古い内容で上書きしてしまう」ことが構造的に起こらなくなります。
3. 導入手順（登録〜設定）
github.comでアカウントを作成し（無料）、ログイン後に「New repository」からリポジトリを新規作成します。このサイトのソースコード自体を公開する意図はないため、公開範囲は必ず「Private（非公開）」を選択します。
Public（公開）とPrivate（非公開）の違い
Publicは誰でも中身を閲覧できるリポジトリ、Privateは招待された本人（＋許可した相手）しか中身を見られないリポジトリです。自宅サーバーの構成が推測できる情報を含むため、必ずPrivateで作成します。
Webサイトの実体があるディレクトリで、既存のファイルをそのまま取り込む形でGit管理を開始します。
cd /var/www/html
git init
git add -A
git commit -m "初回コミット：既存サイトを取り込み"サーバーからGitHubへパスワード無しで安全に接続するため、このリポジトリ専用のSSH鍵（デプロイキー）を作成します。自分のGitHubアカウント本体のログイン鍵とは別に、「このリポジトリだけにアクセスできる専用の鍵」を用意するのがポイントです。
ssh-keygen -t ed25519 -f ~/.ssh/<デプロイ鍵のファイル名> -N ""生成された公開鍵（.pubの方）の中身を、GitHubリポジトリの「Settings → Deploy keys → Add deploy key」から登録します。サイトの更新にはpush（書き込み）も行うため、「Allow write access」にチェックを入れて登録します。
サーバー上のGitリポジトリに、GitHub側の接続先（originという名前で管理するのが慣習）を登録し、SSH接続時にSTEP 3の専用鍵を使うよう設定します。
git remote add origin git@github.com:<あなたのGitHubアカウント>/<リポジトリ名>.gitgit push -u origin masterここまでできれば導入完了
GitHub側のリポジトリを開き、サイトのファイル一覧が表示されていれば成功です。以降は「編集のたびにpushする」だけで、変更履歴がすべてGitHub上に記録され続けます。
4. 日常の運用フロー（毎回この順番を守る）
実際にファイルを編集するたびに、必ず次の4ステップを守るようにしています。
① git pull ← 作業を始める前に、必ず最新版を取り込む
│
▼
② ファイルを編集 ← 実際の作業
│
▼
③ git add -A
git commit -m "..." ← 変更内容に短いメモを添えて記録
│
▼
④ git push ← GitHubへアップロードして「正本」を更新- 編集前：
git pullで他の端末・他のセッションの最新変更を必ず取り込む - 編集後：
git add -A && git commit -m "内容の要約"で変更を記録する - 最後に：
git pushでGitHubへ反映する（ここを忘れると「手元だけの変更」で終わってしまう）
5. 競合（コンフリクト）が起きたときの対処
複数の端末がほぼ同時に作業していると、まれにgit pushが失敗（reject）することがあります。これは事故ではなく、「他の誰かが自分より先にpushした」ことをGitが正しく検知して、上書き事故を未然に防いでくれているサインです。
- まず慌てず
git pullを実行し、先にpushされた最新内容を取り込む - 同じ箇所を両方が編集していた場合のみ、Gitが競合箇所を教えてくれるので、どちらの内容を残すか（または両方活かすか）を手動で確認・修正する
- 解決したら、通常通り
git add -A && git commit -m "..."→git push
以前の運用との決定的な違い
Git導入前は「後からアップロードした方が黙って勝つ」上書き運用でした。Git導入後は「先にpushされていたら、必ず一度立ち止まって確認を挟む」運用に変わったのが、今回の事故防止の本質です。
6. 導入して良かったこと・気をつけていること
■ 良かったこと
- 上書き事故がなくなった：先にpushされた変更に気づかず消してしまう、という事故の構造そのものが解消された。
- 変更履歴が残る：「いつ・何を・なぜ直したか」がコミットメッセージとして時系列で残るので、後から見返せる。
- 間違えても戻せる安心感：過去のどの時点の状態にも戻せるため、思い切って修正・実験がしやすくなった。
■ 気をつけていること
- 作業前のpullを絶対に忘れない：ここを省略すると、Git導入前と同じ事故が再び起こり得る。
- 公開範囲の設定ミスに注意：誤ってPublic（公開）で作成しないよう、作成直後に必ず設定を確認する。
- サイズの大きい画像などの扱い：大容量ファイルを頻繁に更新すると履歴が肥大化しやすいため、不要になった旧ファイルは適宜整理する。
複数端末での安全なサイト更新体制、これで整理完了 🎉
Git／GitHubの基礎知識から、実際の導入手順・日常運用・競合対処までをまとめました。同じように個人サイトを複数端末で更新している方の参考になれば幸いです。