ローカルGitで管理していたAstroサイトをGitHubに登録してみた｜PrivateリポジトリとHTTPS認証
はじめに
WordPressからAstroへの移行作業を進める中で、Gitを使って変更履歴を管理するようになりました。
これまではMacのローカル環境でGitを使用していましたが、今後もAstroで記事を追加していくことを考えると、GitHubにも保存しておいた方が便利そうです。
そこで今回、GitHubにPrivate（非公開）リポジトリを作成し、ローカルのAstroプロジェクトを登録することにしました。
この記事では、実際に行ったGitHubへの登録手順と、作業中に疑問に思ったことを整理します。
今回の環境は以下のとおりです。
- OS：macOS
- Webサイト：Astro
- バージョン管理：Git
- 保存先：GitHubのPrivateリポジトリ
- 接続方式：HTTPS
- 認証ヘルパー：osxkeychain
1. そもそもGitとGitHubは何が違う？
最初に整理しておきたいのが、GitとGitHubの違いです。
Gitは、ファイルの変更履歴を管理するためのツールです。
GitHubは、Gitで管理しているリポジトリをオンライン上で保管・共有できるサービスです。
つまり、GitHubを使わなくてもGitによる履歴管理はできます。
今回も、Astroの移行作業中はローカルのGitだけで管理していました。
では、なぜGitHubを使うことにしたのでしょうか。
理由は、今後のサイト管理を考えたためです。
GitHubにリポジトリを保存しておけば、別のパソコンでも作業を続けやすくなります。
また、ローカルのMacが故障した場合でも、GitHubに送信済みのソースコードとコミット履歴は残ります。
ただし、GitHubは完全なバックアップの代わりではありません。未コミットの変更やGitで管理していないファイルまでは保存されません。
2. GitHubでPrivateリポジトリを作成する
まずGitHubにサインインします。
リポジトリの作成画面を開きます。
ここで、リポジトリ名を入力します。
今回は個人で管理するAstroのプロジェクトなので、公開範囲は Private にしました。
PublicとPrivateの違い
| 設定 | 内容 |
|---|---|
| Public | 誰でもリポジトリを閲覧できる |
| Private | 許可されたユーザーだけが閲覧できる |
個人サイトのソースコードを非公開で管理したい場合は、Privateが選択肢になります。
ただし、Privateであっても、パスワードやAPIキーなどを保存してよいわけではありません。
READMEは新しく作成する？
GitHubの新規リポジトリ作成画面には、READMEファイルを追加する項目があります。
今回は、チェックを入れませんでした。
というのも、Astroのブログ用テンプレートからプロジェクトを作成していたため、ローカルにすでに README.md が存在していたからです。
内容は、まだAstroのテンプレートのままです。
GitHub側で新しくREADMEを作成すると、ローカルとは別に最初のコミットが作られ、初回の同期時に追加の操作が必要になる場合があります。
そのため、今回はGitHub側ではREADME、.gitignore、ライセンスを新規作成せず、空のリポジトリを用意しました。
READMEは、GitHubへの登録後に自分のプロジェクトに合わせて編集する予定です。
3. ローカルのGit管理状況を確認する
GitHubに接続する前に、ターミナルでAstroのプロジェクトディレクトリへ移動します。
cd プロジェクト名
最初に確認するのは、Gitの管理場所です。
git rev-parse --show-toplevel
これは、現在のGitリポジトリのルートディレクトリを表示します。
今回のAstro移行では、以前、Gitの管理ディレクトリを間違えたことがありました。
そのため、今後は最初に確認する習慣をつけたいと思っています。
次に、変更状況を確認します。
git status
現在のブランチも確認します。
git branch --show-current
今回は main ブランチをGitHubへ送信する構成です。
GitHubへ送ってはいけないファイルは？
GitHubへアップロードする前に、.gitignore を確認します。
Astroのプロジェクトでは、一般的に次のようなファイルやディレクトリをGit管理から除外します。
node_modules/
dist/
.env
.env.*
!.env.example
node_modules/ はインストールした依存パッケージ、dist/ は通常の静的ビルドで生成される公開用ファイルです。
これらは、一般的にはGitHubへ保存する必要がありません。
一方、package.json と package-lock.json は通常Gitで管理します。
ただし、.gitignore に追加しただけでは、すでに追跡されているファイルは自動的にGit管理から外れません。
もし認証情報をコミットしてしまっていた場合は、ファイルの除外だけでなく、資格情報の無効化や履歴からの除去も検討する必要があります。
4. GitHubのリポジトリを登録する
GitHubに空のリポジトリを作成すると、接続用のURLが表示されます。
HTTPSの場合は、次のような形式です。
https://github.com/ユーザー名/リポジトリ名.git
ターミナルで次のコマンドを実行します。
git remote add origin https://github.com/ユーザー名/リポジトリ名.git
origin は、接続先のリポジトリに付ける名前です。
通常、最初に登録するリモートリポジトリには origin という名前を使います。
接続先を確認します。
git remote -v
例えば、次のように表示されます。
origin https://github.com/ユーザー名/リポジトリ名.git (fetch)
origin https://github.com/ユーザー名/リポジトリ名.git (push)
fetch は取得、push は送信の接続先を示しています。
なお、すでに origin が登録されている場合は、同じ名前で追加できません。
エラーが出た場合は、既存の接続先を確認してから対応します。
5. 初めてGitHubへpushする
いよいよ、ローカルで管理しているAstroのプロジェクトをGitHubへ送信します。
今回実行したコマンドはこちらです。
git push -u origin main
このコマンドには、それぞれ意味があります。
| 記述 | 意味 |
|---|---|
git push |
リモートリポジトリへ送信 |
-u |
追跡先ブランチを設定 |
origin |
登録したリモートリポジトリ |
main |
送信するローカルブランチ |
-u によって追跡先を設定しておくと、次回からは通常、次のコマンドだけで送信できます。
git push
実行後、GitHubのブラウザ画面を開いて確認しました。
Astroのファイルがリポジトリに表示されていれば、初回の送信は成功です。
6. なぜGitHubの認証画面が出なかったのか？
今回、少し不思議だったことがあります。
git push -u origin main を実行したところ、追加の認証画面が表示されることなく、アップロードできました。
最初は、ブラウザでGitHubにサインインしていたからだろうかと思いました。
ところが、ブラウザでGitHubにサインインしていることと、ターミナルでのGit認証は必ずしも同じではありません。
実は以前、別の開発作業でGitHubのHTTPS認証を設定した記憶がありました。
Dockerを使っていた頃の作業だったかもしれません。
そこで、Gitの認証情報を管理する設定を確認してみることにしました。
6-1. 認証ヘルパーを確認する
ターミナルで次のコマンドを実行します。
git config --show-origin --get-all credential.helper
今回の結果は、
osxkeychain
でした。
osxkeychain は、macOSのキーチェーンを利用してGitのHTTPS認証情報を管理する仕組みです。
つまり、過去に保存した認証情報が、今回のGitHub接続でも利用された可能性があります。
ただし、このコマンドで確認できるのは認証ヘルパーの設定です。
実際にどの認証情報が使用されたのか、いつ保存したのかまでは分かりません。
また、Docker自体がGitHubの認証を設定したと断定することもできません。
以前のDocker関連の開発作業中にGitHubを利用していた可能性はありますが、詳細は不明です。
6-2. 初めてGitHubを利用する場合は？
今回のように、過去の認証設定が利用できない場合は、別途GitHubの認証が必要になります。
GitHubでは、HTTPSで接続する場合、個人アクセストークン（PAT）やGit Credential Manager、GitHub CLIなどを使用する方法があります。
現在、GitHubアカウントの通常のパスワードを、GitのHTTPS操作の認証パスワードとして使用することはできません。
認証方法は、GitHubの公式ドキュメントを確認してください。
なお、認証情報が正常に利用できているのであれば、わざわざ設定を変更する必要はありません。
7. 次回からはどうやってGitHubを更新する？
初回の push が成功し、追跡先ブランチが設定されていれば、今後の更新は簡単になります。
例えば、Astroの記事やCSSを変更した場合です。
まず、現在の状態を確認します。
git status
変更内容を確認します。
git diff
必要な変更をステージします。
git add .
コミットする内容を確認します。
git diff --staged
コミットします。
git commit -m "Update blog"
最後にGitHubへ送信します。
git push
これで、GitHubにも変更履歴が反映されます。
ちなみに、コミットメッセージは日本語でも構いません。
git commit -m "ブログ記事を追加"
今回は英語の表現にも慣れるため、英語のコミットメッセージも使っています。
git commit と git push の違い
この2つは別の操作です。
git commit はローカルのGitに変更履歴を記録します。
git push は、そのコミットをGitHubなどのリモートリポジトリへ送信します。
つまり、コミットしただけではGitHubには反映されません。
8. GitHubに送信したらWebサイトも更新される？
ここも重要なポイントです。
GitHubへのpushと、Webサイトの公開は別の操作です。
今回のAstroサイトは、ローカルでビルドして生成されたファイルを、レンタルサーバーへ配置する運用を前提にしています。
通常の静的サイト構成では、
npm run build
によって、dist ディレクトリに公開用のファイルが生成されます。
GitHubにはソースコードと変更履歴を保存し、Webサイトの公開は別途行います。
将来的にはGitHub Actionsなどを使って、GitHubへのpushをきっかけにビルド・公開を自動化する方法もあります。
ただし、今回はそこまで設定していません。
まずは、Gitによる変更履歴の管理と、GitHubへの保存・同期を安定させることを優先します。
9. GitHubを使うときに注意したいこと
Privateでも機密情報を保存しない
Privateリポジトリは一般公開されませんが、機密情報を保存してよい場所ではありません。
APIキー、パスワード、秘密鍵などはコミットしないようにします。
git push を忘れない
ローカルでコミットしても、GitHubへ送信しなければリモート側には反映されません。
作業を区切るタイミングで、pushまで済んでいるか確認します。
READMEはプロジェクト用に書き換える
今回、GitHubに登録したREADMEは、Astroのブログ用テンプレートに付属していたものです。
今後は、サイトの目的、開発方法、記事の追加方法、公開手順などを記述する予定です。
READMEを整備しておけば、別のパソコンで作業するときや、時間が経ってから作業を再開するときにも役立ちます。
GitHubだけをバックアップにしない
GitHubには、送信したコミット履歴や追跡対象のファイルが保存されます。
ただし、未コミットの作業やGitで管理していないファイルは保存されません。
また、WordPressからの移行で取得したバックアップデータなどは、別途安全な場所で保管する必要があります。
10. よく使うGitHub関連コマンド
| コマンド | 用途 |
|---|---|
git remote -v |
接続先を確認 |
git branch --show-current |
現在のブランチを確認 |
git push -u origin main |
初回pushと追跡設定 |
git push |
コミットを送信 |
git fetch origin |
リモートの更新情報を取得 |
git pull --ff-only |
早送り可能な場合だけ取得・統合 |
git status |
ローカルの変更状況を確認 |
git log --oneline |
コミット履歴を確認 |
git config --show-origin --get-all credential.helper |
Git認証ヘルパーを確認 |
複数のパソコンで作業する場合は、作業を始める前にリモート側の変更を取得し、作業終了後にコミット・pushする流れを意識したいと思います。
おわりに
今回、ローカルGitで管理していたAstroプロジェクトを、GitHubのPrivateリポジトリに登録しました。
実際の操作は、それほど複雑ではありませんでした。
ただし、GitとGitHubの違い、コミットとpushの違い、HTTPS認証の仕組みなど、理解しておいた方がよいこともあります。
今回、特に印象に残ったのは、追加の認証なしでGitHubへpushできたことです。
調べてみると、macOSのキーチェーンを使用する osxkeychain が設定されていました。
以前の開発作業で設定した認証情報が利用された可能性があり、Gitの認証情報が再利用される仕組みについても知る機会になりました。
今後は、Astroの記事追加やデザインの変更をGitで記録しながら、GitHubにも定期的に送信していこうと思います。
まずは手動で確実に管理し、慣れてきたら公開作業の自動化も検討してみたいと思います。