【Next.jsブログ構築】VPS の Next.js ブログを Git と GitHub でバックアップ・バージョン管理する方法

これまでの Next.js ブログ構築シリーズをまとめたページはこちらです。

前回の記事はこちらです。

VPS でサイトを運用していると、
ふとした瞬間に「もしサーバーが壊れたら、どうなるのだろう」と不安になることがあります。

私の Next.js ブログは Cursor というエディタで VPS に直接接続して開発しており、
ソースコードは VPS 上にしか存在しない状態でした。
つまり、VPS が何らかの理由でデータを失った場合、
第 1 回から積み上げてきたコードがすべて消える可能性があります。

この記事では、その問題を解決するために Git と GitHub を使った
バックアップ・バージョン管理の環境を構築した手順を解説します。

バックアップとしての役割だけでなく、
機能追加やデザイン変更をするたびに変更履歴が残るため、
「前の状態に戻したい」というときにも対応できます。
コマンドラインでの操作に加え、
Cursor の GUI でも同じ操作ができる方法もあわせて紹介します。

この記事を読むとわかること：

• なぜ VPS 単体でのソースコード管理が危険なのか
• Git と GitHub を使ったバックアップの仕組み
• GitHub アカウントの作成から初回 push までの手順
• Cursor の GUI を使った日常的な commit と push の方法

なぜバックアップが必要なのか

私が Next.js ブログを開発している環境は、次のような構成です。

• Cursor：SSH リモート接続で VPS 上のファイルを直接編集するエディタ
• VPS：ソースコードの実体が置かれている場所（~/example-blog/）
• Windows PC：ソースコードのローカルコピーは存在しない

Cursor は VPS に接続してファイルを編集しているだけで、PC 側にはコードは保存されていません。
そのため、VPS に障害が起きた場合やサーバーを誤って初期化してしまった場合、ソースコードが完全に失われます。

また、バックアップとは別に「バージョン管理」の問題もあります。
新しい機能を追加してうまく動かなくなったとき、変更前の状態に戻す手段がありません。

これらの問題を解決するのが、Git と GitHub を組み合わせた仕組みです。

バックアップ方法の比較

ソースコードのバックアップ方法はいくつか考えられます。
今回採用した方法を選んだ理由をあわせて紹介します。

方法① WinSCP で手動ダウンロード

VPS のファイルを WinSCP などの SFTP クライアントで PC にダウンロードする方法です。

設定なしで今すぐ始められる手軽さが魅力ですが、「いつの時点のファイルか」がわからないこと、手動なので忘れがちになること、任意の時点に戻す仕組みがないことが弱点です。

方法② Git + GitLab

GitHub の代替サービスである GitLab を使う方法です。
無料でプライベートリポジトリが使える点は GitHub と同じで、操作方法もほぼ変わりません。

GitLab のほうが一部の機能で優れている面もありますが、利用者数や日本語の情報量の面では GitHub に軍配が上がります。

方法③ Git + GitHub（採用）

今回採用した方法です。

項目	評価
バージョン管理	✅ 変更履歴がすべて残る
任意の時点への復元	✅ commit ID を指定して戻せる
自動化	✅ push 1コマンドで GitHub に送信できる
費用	✅ プライベートリポジトリが完全無料
情報量	◎ 世界標準・日本語情報も豊富

GitHub を選んだ最大の理由は「業界標準であること」です。
困ったときに調べやすく、わからないことがあっても解決策を見つけやすい環境が整っています。

このタイミングでようやく Git ＋ GitHub でソースコードのバックアップと変更履歴の管理ができるようにしたのですが、今思えば、もっと早いタイミングで導入しておくべきでした。

これまで Next.js ブログサイトを構築してくる過程では、作業に失敗してサイトが表示されなくなるようなこともありました。

そういうときに、元の状態に戻せる環境を作っておくのは、とても重要です。

「これから開発を始める」という段階から、準備しておくべきです。

GitHub について

無料プランで使えるか

2020 年 4 月以降、GitHub のプライベートリポジトリは完全に無料で使えるようになりました。
個人利用であれば費用は一切かかりません。

主な制限は以下のとおりです。

制限	内容
1ファイルの上限	100MB を超えるファイルはアップロード不可
リポジトリの推奨サイズ	1GB 以下を推奨

node_modules/ や .next/ などの大きなフォルダは後述の .gitignore で除外するため、Next.js ブログのソースコードであれば制限を気にする必要はほぼありません。

プライバシーについて

プライベートリポジトリに設定すれば、自分以外は誰もコードを見ることができません。
ただし、リポジトリ作成時のデフォルトは「Public（公開）」になっているため、必ず「Private（非公開）」を選ぶ必要があります。

API キーや SSH 秘密鍵などの機密情報は、プライベートリポジトリであっても .gitignore で除外することが基本です。

環境構築の手順

STEP 1：GitHub アカウントを作成する

ブラウザで以下の URL を開きます。

https://github.com/signup

アカウントの作成方法としては、メールアドレスとパスワードを登録する方法のほか、Google アカウントや、Apple ID で登録する方法もあります。

Google アカウントで登録すると、パスワードを別途管理する必要がなく、Google の 2 段階認証がそのまま適用されるため便利です。

Username（ユーザー名）について

Username は GitHub の URL に含まれる識別名です。
英数字とハイフンのみ使用可能で、後から変更もできます。
実名や個人情報を含まない名前にすることをお勧めします。

GitHub のサインアップ画面です。
メールアドレスによる登録以外に、Google アカウントや Apple ID で登録する方法もあります。

「Create account」ボタンをクリックしてアカウントを作成します。

STEP 2：2段階認証（2FA）を設定する

Settings → Password and authentication から「Enable two-factor authentication」をクリックします。

2 段階認証とは、ログイン時にパスワードに加えてスマートフォンの認証アプリで発行した 6 桁のコードを要求する仕組みです。
万一パスワードが漏れた場合でも不正ログインを防げます。

SMS 認証という方法もありますが、認証アプリを使う方法のほうが安定しているためお勧めです。
代表的なアプリとして Google Authenticator や Microsoft Authenticator が無料で利用できます。

設定の流れ：

1. スマートフォンの認証アプリで QR コードを読み取る
2. アプリに表示された 6 桁のコードを入力して「Continue」をクリックする
3. バックアップコードが表示される（必ず安全な場所に保存する）
4. 確認して設定完了

バックアップコードはスマートフォンを紛失したときの緊急用コードです。1 回使うと無効になります。

STEP 3：メールアドレスのプライバシー設定をする

Settings → Emails から「Keep my email addresses private」を ON にします。

Git の仕組み上、commit（変更の記録）にメールアドレスが含まれます。
この設定を ON にすると、実際のメールアドレスの代わりに GitHub が発行するダミーアドレスが使われるため、メールアドレスが外部に漏れません。

この設定を ON にすると「Block command line pushes that expose my email」も自動的に ON になり、二重に保護されます。

「Keep my email addresses private」を ON にすると、GitHub が発行するダミーアドレスが使えるようになります。

STEP 4：プライベートリポジトリを作成する

ダッシュボードの「Create repository」ボタンをクリックします。

設定内容は以下のとおりです。

項目	設定値
Repository name	example-blog（自分のブログフォルダ名）
Description	任意（例：Next.js blog source code backup）
Visibility	Private（必ず選ぶ）
Add README	Off
Add .gitignore	No .gitignore
Add license	No license

Visibility の設定が最も重要です。
デフォルトは Public になっているため、必ず Private に変更してから「Create repository」をクリックします。

リポジトリの作成画面です。
「Choose visibility」が上の画面では、Public になっていますが、これを必ず Private に変更してください。

リポジトリが作成されると、次のような画面が表示されます。
この画面には後の手順で使う SSH アドレスが含まれているため、開いたままにしておきます。

リポジトリ作成直後の画面です。
「Quick setup － if you’ve done this kind of thing before」の下あたりに、「HTTPS」と「SSH」のボタンが見えます。

STEP 5：VPS の Git を確認する

VPS に SSH 接続してターミナルを開きます。
以下のコマンドで Git のインストール状況を確認します。

git --version

git version 2.xx.x のように表示されればインストール済みです。

インストールされていない場合は以下のコマンドでインストールします。

sudo apt update

sudo apt install -y git

• sudo apt update：パッケージ情報を最新の状態に更新する
• sudo apt install -y git：Git をインストールする。-y は確認をスキップするオプション

STEP 6：GitHub 専用の SSH 鍵を生成する

VPS から GitHub に接続するための SSH 鍵を生成します。

ssh-keygen -t ed25519 -C "github-deploy-key"

• ssh-keygen：SSH 鍵を生成するコマンド
• -t ed25519：鍵の種類を指定する。ed25519 は現在最も推奨されている方式
• -C "github-deploy-key"：鍵の用途を示すコメント（ご自身でわかりやすく鍵の名前をつけてください）

コマンドを実行すると保存場所を聞かれます。
VPS にすでに別の SSH 鍵がある場合は、上書きを防ぐために別の名前で保存します。

Enter file in which to save the key (/home/username/.ssh/id_ed25519):

以下のように入力します。username は自分の VPS のユーザー名に置き換えてください。

/home/username/.ssh/id_ed25519_github

次にパスフレーズを聞かれますが、今回は空のまま Enter を 2 回押します。
将来的に push の自動化を行う場合にパスフレーズがあると妨げになるためです。

SSH 鍵は 2 つのファイルとして生成されます。

ファイル	種類	扱い
id_ed25519_github	秘密鍵	絶対に外部に出さない
id_ed25519_github.pub	公開鍵	GitHub に登録する

公開鍵は「南京錠」、秘密鍵は「その南京錠を開ける鍵」のイメージです。
GitHub に南京錠を登録しておくことで、その鍵を持つ VPS だけが push できるようになります。

STEP 7：公開鍵を GitHub に登録する

公開鍵の内容を確認します。

cat ~/.ssh/id_ed25519_github.pub

ssh-ed25519 で始まる 1 行のテキストが表示されます。この内容をコピーします。

GitHub の Settings → SSH and GPG keys → 「New SSH key」をクリックして登録します。

項目	入力値
Title	鍵の用途がわかる名前（例：VPS-myblog）
Key type	Authentication Key（デフォルトのまま）
Key	コピーした公開鍵を貼り付ける

GitHub のアカウントの Settings から SSH and GPG keys を選択した画面です。
SSH keys の右側（上の画面では右上）にある New SSH key をクリックしてください。

New SSH key をクリックしたあとに表示される画面です。
後で見てわかるように、鍵の名前（Title）を入力し、公開鍵を Key に貼り付けてください。

STEP 8：SSH config を設定する

GitHub への接続時に自動的に正しい鍵を使うよう設定します。

nano ~/.ssh/config

以下の内容を入力して保存します（Ctrl + O → Enter → Ctrl + X）。

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

• Host github.com：github.com に接続するときにこの設定を使う
• HostName github.com：接続先のサーバー名
• User git：GitHub への接続では常に git を使う（個人のユーザー名ではない）
• IdentityFile：使用する秘密鍵のパス

STEP 9：接続テストをする

GitHub への接続が正しく設定されているか確認します。

ssh -T git@github.com

初回接続時に以下のメッセージが表示されたら yes と入力します。

Are you sure you want to continue connecting (yes/no/[fingerprint])?

接続が成功すると以下のように表示されます。

Hi GitHubユーザー名! You've successfully authenticated, but GitHub does not provide shell access.

「認証に成功しました」という意味です。
「shell access を提供していない」という部分は GitHub がコマンド実行用サーバーではないため表示されるもので、正常な結果です。

STEP 10：Git のユーザー情報を設定する

commit に記録される名前とメールアドレスを設定します。

git config --global user.name "GitHubのユーザー名"

git config --global user.email "GitHubで発行されたダミーアドレス"

ダミーアドレスは、STEP 3 で設定した「Keep my email addresses private」を ON にした際に GitHub が自動発行したものです。
GitHub の Settings → Emails に表示されている 数字+ユーザー名@users.noreply.github.com の形式のアドレスを使います。

設定を確認します。

git config --global --list

user.name と user.email が正しく表示されれば完了です。

STEP 11：Git を初期化する

~/example-blog/ ディレクトリに移動します。

cd ~/example-blog

Git リポジトリとして初期化します。

git init

このコマンドを実行すると ~/example-blog/ 内に .git という隠しフォルダが作成されます。
Git はこのフォルダにすべての変更履歴を保存します。
このフォルダは絶対に削除しないでください。

次に、GitHub のデフォルトブランチ名に合わせてブランチ名を main に変更します。

git branch -M main

STEP 12：.gitignore を設定する

.gitignore は「Git 管理から除外するファイルやフォルダの一覧」です。
ビルド時に自動生成されるファイルや、容量の大きい依存パッケージなどを除外することで、リポジトリをすっきり保てます。

Next.js プロジェクトを作成すると .gitignore がすでに存在しています。
内容を以下のように更新します。

nano ~/example-blog/.gitignore

# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.

# dependencies
/node_modules

# next.js
/.next/
/out/

# production
/build

# misc
.DS_Store
*.pem

# debug
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# env files
.env*

# typescript
*.tsbuildinfo

# SQLite database
data/
*.db

# backup files
*.bak

各項目の意味を説明します。

項目	説明
/node_modules	依存パッケージ。npm install で自動復元できるため除外
/.next/・/out/	ビルド時に自動生成されるフォルダ
/build	ビルド生成物
.DS_Store	Mac の隠しファイル。念のため除外
*.pem	証明書ファイル。機密情報のため除外
.env*	環境変数ファイル全般。機密情報が含まれる可能性があるため除外
*.tsbuildinfo	TypeScript のビルドキャッシュ
data/・*.db	第18〜19回で導入した SQLite データベース。Git 管理には向かないため除外
*.bak	バックアップファイル。Git があれば不要なため除外

Ctrl + O → Enter → Ctrl + X で保存します。

STEP 13：初回 commit をする

すべてのファイルをステージング（commit の準備）に追加します。

git add .

• git add：ファイルを commit の対象として追加する
• .（ドット）：現在のフォルダ内のすべてのファイルを対象にする（.gitignore で除外されているものは除く）。ドットを忘れずに入力してください

.gitignore が正しく機能しているか確認します。

git status

node_modules/ や data/ が表示されていなければ除外されています。

commit を実行します。

git commit -m "初回コミット：Next.jsブログ構築シリーズ完了時点のソースコード"

• git commit：ステージングのファイルを変更履歴として記録する
• -m "..."：この commit の内容を説明するメッセージ

commit とは「この時点のスナップショットを撮って保存する」操作です。
変更のたびに commit することで、過去の任意の時点のコードに戻せるようになります。

STEP 14：GitHub と紐づけて push する

VPS の Git リポジトリと GitHub のリポジトリを紐づけます。

まず、STEP 4 で作成したリポジトリの画面を開き、「SSH」タブをクリックします。
表示された git@github.com:GitHubユーザー名/リポジトリ名.git という形式の SSH アドレスをコピーします。

そのアドレスを使って以下のコマンドを実行します。

git remote add origin git@github.com:GitHubユーザー名/example-blog.git

• git remote add：リモートリポジトリ（GitHub）の場所を登録する
• origin：リモートリポジトリの呼び名。慣習的に最初のリモートは origin と名付ける
• git@github.com:...：コピーした SSH アドレス

GitHub に push します。

git push -u origin main

• git push：ローカルの commit を GitHub に送信する
• -u origin main：初回のみ必要。次回以降は git push だけで送信できるようになる

STEP 15：GitHub 上でファイルを確認する

ブラウザで GitHub のリポジトリページを開き、ファイルが届いていることを確認します。

確認するポイント：

• 「Private」バッジが表示されている
• app/・components/・posts/ などのフォルダが表示されている
• node_modules/・data/・.next/ が表示されていない（正しく除外されている）

リポジトリページを表示した画面です。
リポジトリ名の横に、Private と表示されており、コミット → プッシュしたデータがリポジトリに保存されていることがわかります。

Git ＋ GitHub を使うことに慣れていないため、ここまで進めるのにとまどうこともありましたが、送信したデータがちゃんと保存されているのを見て、これでサイトのバックアップができるようになったと安心できました。

日常的な操作方法

環境構築が完了したあとの日常的な操作を紹介します。
CLI（コマンドライン）と Cursor の GUI、どちらでも同じ結果になります。
使いやすい方を選んでください。

CLI での操作

作業が完了するたびに、以下の 3 つのコマンドを実行します。

git add .

git commit -m "作業内容がわかるメッセージ"

git push

commit メッセージの書き方

メッセージは後から見て「この時点で何をしたか」がわかることが重要です。

良い例：

第24回：SQLiteDBをrcloneでOneDriveに自動バックアップ
サイドバーのデザインを調整
ViewCounter.tsxのバグ修正

悪い例：

修正
update
作業

Cursor の GUI での操作

ターミナルを開かずに、Cursor のソース管理パネルから同じ操作ができます。

前提：Cursor で ~/example-blog/ フォルダを開いていること

Cursor のエクスプローラー（左サイドバーのファイルアイコン）のフォルダツリーの先頭が EXAMPLE-BLOG [SSH: サーバー名] になっていれば、ソース管理パネルが正しく機能します。

別のフォルダが開かれている場合は ~/example-blog/ を開き直してください。

① ファイルを変更する

ファイルを編集して保存すると、タブに「M」マークが表示されます。
「M」は「Modified（変更済み）」の意味です。
左側のファイル一覧にも同じ「M」マークが表示されます。

試しに README.md ファイルに変更を加えたところです。
画面上のタブのファイル名の横、フォルダツリーのファイル名の横に、「M」マークが表示されています。

② ソース管理パネルを開く

左サイドバーのソース管理アイコン（分岐したアイコン）をクリックします。
「変更」セクションに、変更されたファイルの一覧が表示されます。

ファイルの右側に表示されるアイコンの意味：

アイコン	意味	CLI との対応
📄	変更内容を別ウィンドウで確認する	git diff に相当
↩️	変更を取り消して元に戻す	git restore に相当
＋	ステージングに追加する	git add に相当

Cursor の左サイドバー上部にある、分岐をイメージしたアイコンをクリックすると、変更されたファイルの一覧が表示されます。

③ ステージングに追加する

変更ファイルの右側の「＋」アイコンをクリックします。ファイルが「変更」から「ステージされている変更」セクションに移動します。これが git add に相当する操作です。

変更されたファイルの右側にある「＋」アイコンをクリックすると上の画面のようになります。
変更されたファイルが、「変更」から「ステージされている変更」に移動します。

④ commit メッセージを入力してコミットする

パネル上部の「メッセージ」欄に commit メッセージを入力し、「✓ コミット」ボタンをクリックします。
これが git commit -m "..." に相当する操作です。

コミットが完了すると「変更の同期 1個」というボタンが表示されます。
これは「GitHub にまだ送信していない commit が 1 件ある」という意味です。

「✓ コミット」ボタンを押すと、「変更の同期 1個」ボタンが表示されます。

⑤ GitHub に push する

「変更の同期 1個」ボタンをクリックします。これが git push に相当する操作です。

初回は以下の確認ダイアログが表示される場合があります。

このアクションは、"origin/main" との間でコミットをプルおよびプッシュします。

これは GitHub との間で「変更の取り込み（プル）」と「送信（プッシュ）」を行う確認です。
「OK、今後は表示しない」をクリックすると次回以降は表示されなくなります。

また、以下のダイアログが表示された場合は「いいえ」を選択します。

Cursor に定期的に「git fetch」を実行するにしますか？

git fetch は GitHub 側の変更を定期的に確認する機能ですが、個人で使うリポジトリでは不要です。

push が完了するとソース管理パネルの変更一覧が空になります。

CLI と Cursor GUI の対応表

操作	CLI	Cursor GUI
変更状態の確認	git status	ソース管理パネルの変更一覧を見る
ステージングに追加	git add .	変更ファイルの「＋」をクリック
コミット	git commit -m "..."	メッセージを入力して「コミット」ボタン
GitHub に送信	git push	「変更の同期」ボタン
変更を取り消す	git restore ファイル名	変更ファイルの「↩️」をクリック

知っておくと役立つ Git コマンド

日常的に使う操作以外にも、知っておくと便利なコマンドを紹介します。

commit 履歴を確認する

git log --oneline

commit の一覧が 1 行ずつコンパクトに表示されます。
各行の先頭にある 7 文字の英数字が commit の ID です。

過去のファイルを確認する

git show コミットID:ファイルパス

特定の時点のファイルの中身を確認できます。

特定のファイルだけ過去の状態に戻す

git restore --source=コミットID ファイルパス

1 つのファイルだけを特定の commit 時点の状態に戻します。

一時的に変更を退避する

git stash

現在の変更を一時的に保存して、作業フォルダをきれいな状態に戻します。
別の作業を急に始めなければならないときに便利です。
保存した変更は git stash pop で元に戻せます。

まとめ

Git と GitHub を使ったバックアップ・バージョン管理の環境が構築できました。

今回の作業で実現したこと：

• VPS が唯一のソースコードという状況を解消し、GitHub にバックアップできた
• 機能追加やデザイン変更のたびに commit することで、任意の時点に戻せる環境ができた
• CLI でも Cursor の GUI でも commit と push ができるようになった

Git は最初は難しく感じるかもしれませんが、日常的に使うコマンドは git add .・git commit -m ""・git push の 3 つだけです。
Cursor の GUI を使えばターミナルを開かずに同じ操作ができるため、コマンドが苦手な方でも続けやすい環境になっています。

次回は SQLite データベースのバックアップについて解説します。
ソースコードとは別に、閲覧数データを OneDrive に自動でバックアップする仕組みを構築します。

公開までしばらくお待ちください。