AstroとGitでよく使うコマンドまとめ｜ファイル削除・変更の取り消し・実際につまずいた操作も解説

はじめに

WordPressで制作したサイトをAstroへ移行することになり、Gitを使ってファイルの変更履歴を管理することにしました。

これまでもHTMLやCSS、PHPなどを編集してきましたが、Gitについてはまだ慣れていない部分があります。

実際に作業してみると、次のような疑問が次々と出てきました。

Astroを起動したままGitを使ってもいい？
新しいファイルを追加したらどうする？
ファイルを削除したときも git add が必要？
間違えて編集したファイルを元に戻したい場合は？
直前のコミットを取り消したい場合は？
コミットメッセージは日本語でもいい？

そこで、今回のAstro移行作業で使ったコマンドと、間違えやすかったポイントを整理してみました。

この記事ではmacOSのターミナルを使用し、AstroプロジェクトをGitで管理する前提で説明します。

1. Astroでよく使うコマンド

まず、AstroでWebサイトを制作する際によく使用するコマンドです。

コマンド	用途
`pwd`	現在のディレクトリを確認
`ls`	ファイル一覧を確認
`node -v`	Node.jsのバージョンを確認
`npm -v`	npmのバージョンを確認
`npm install`	依存パッケージをインストール
`npm run dev`	開発サーバーを起動
`npm run build`	公開用のファイルを生成
`npm run preview`	ビルドしたサイトを確認
`npx astro --version`	Astroのバージョンを確認

ブログ用テンプレートでAstroを作成する

今回、Astroのプロジェクトを作成するときは、ブログ用のテンプレートを使用しました。

npm create astro@latest -- --template blog

--template blog は、ブログ用のテンプレートを指定するオプションです。

最初から必要なファイルをすべて作成するのではなく、用意された構成をベースにして作業を始めました。

ただし、今回は途中でWordPressのデザインを再現する方針から、Astro用のオリジナルデザインへ変更しています。

開発サーバーを起動する

npm run dev

開発サーバーを終了するには、ターミナルで Control + C を押します。

開発サーバーを起動したままGitを操作したい場合は、別のターミナルを開くと便利です。

ただし、新しく開いたターミナルでも、プロジェクトのディレクトリへ移動してからコマンドを実行します。

公開用ファイルを生成する

npm run build

通常の静的サイト構成では、dist ディレクトリに公開用のHTMLやCSSなどが生成されます。

npm run preview

で、ビルド後の表示を確認できます。

npm run dev は開発中の確認、npm run build は公開用ファイルの生成、npm run preview は生成結果の確認、と覚えると分かりやすいと思います。

2. Gitでよく使うコマンド

コマンド	用途
`git status`	変更状況を確認
`git diff`	ステージ前の変更内容を確認
`git add ファイル名`	指定したファイルをステージ
`git add .`	現在のディレクトリ以下の変更をステージ
`git add -u`	追跡済みファイルの変更・削除をステージ
`git diff --staged`	コミットする変更内容を確認
`git commit -m "内容"`	コミットする
`git log --oneline`	コミット履歴を確認
`git restore ファイル名`	未ステージの変更を取り消す
`git restore --staged ファイル名`	ステージから外す
`git revert HEAD`	直前のコミットを打ち消す新しいコミットを作る

Gitはファイルの変更履歴を管理するツールです。

GitHubとは別のもので、GitHubにアップロードしなくても、ローカルのGitで変更履歴を管理できます。

3. 今回のAstro移行でGitを使ったタイミング

3-1. 最初のコミットで管理ディレクトリを間違えた

今回、Git管理を始める際に、最初のコミットを作成しました。

コミットメッセージは、

chore: initialize Astro blog

でした。

ところが、あとから確認すると、Gitを初期化した場所がAstroプロジェクトの親ディレクトリでした。

確認できたコミットIDは次のとおりです。

58a465a chore: initialize Astro blog

しかも、コミットされた内容は、期待していたAstroのソースコード一式ではありませんでした。

.DS_Store と、別のGitリポジトリとして認識された web-pigyanyan-lab が記録されていました。

つまり、Gitを使い始めたつもりでも、管理する場所を間違えていたのです。

Gitの管理場所を確認する

次のコマンドを使います。

git rev-parse --show-toplevel

これは、現在のGitリポジトリのルートディレクトリを表示します。

ここが意図したAstroプロジェクトの場所になっているか確認します。

特に、プロジェクトの中に別のGitリポジトリがある場合は注意が必要です。

Gitの管理を始める前に、どのディレクトリが管理対象になるのかを確認しておくべきだと分かりました。

※今回、誤って作成した親側のGit管理情報は整理しました。.git は履歴そのものを保存する重要なディレクトリなので、通常の作業で安易に削除してはいけません。

3-2. WordPressの画像を追加した

次に、WordPressから移行した画像ファイルをAstroの public ディレクトリに追加しました。

このとき使用したのが、次のコマンドです。

git add public/

public/ 内の変更をステージします。

コミット前には、追加する内容を確認しました。

git --no-pager diff --cached --stat

--stat を指定すると、変更されたファイルと追加・削除行数などを要約して表示します。

画像ファイルの場合も、どのファイルが変更対象か確認できます。

今回の画像追加では、31件の画像をまとめて扱いました。

そのときのコミットメッセージは、次のとおりです。

git commit -m "assets: add WordPress images"

assets は画像などの素材を扱ったことを表すために使用した接頭辞です。

後から履歴を見たときに、何を追加したのか分かるようにしています。

3-3. 古いルーティングファイルを整理する

Astroの記事URLの構成を変更する際、以前使用していたルーティング用ファイルが不要になりました。

例えば、次のようなファイルです。

src/pages/
└── 2026/
    └── [month]/
        └── [day]/
            └── [slug]/
                └── index.astro

不要になったファイルを削除した場合、その削除もGitで記録する必要があります。

今回の作業では、次のようなコマンドを使う方法を確認しました。

git add -u src/pages/2026/

-u は、すでにGitで追跡しているファイルの変更や削除をステージするオプションです。

新しく作成したファイルは対象になりません。

削除を含む変更内容を確認し、ビルドが成功したらコミットします。

コミットメッセージの例は次のとおりです。

git commit -m "refactor: remove legacy post routes"

これは作業時に提案されたメッセージ例です。

実際にこのメッセージでコミット済みかどうかは、Gitの履歴で確認する必要があります。

4. ファイルを削除したときのGit操作

ここは間違えやすいところです。

ファイルを削除したらGitはどうなる？

例えば、Gitで管理している old-page.astro を削除したとします。

次のコマンドで確認します。

git status

すると、削除されたファイルが deleted として表示されます。

削除したことも変更履歴として記録する必要があります。

方法① 通常の削除後にGitへ反映する

git add -u
git commit -m "Remove old page"

git add -u は、追跡済みファイルの変更と削除をステージします。

方法② Gitコマンドで削除する

git rm old-page.astro
git commit -m "Remove old page"

git rm を使うと、作業ディレクトリからファイルを削除すると同時に、その削除がステージされます。

ただし、すでにファイルを削除している場合は、通常 git add -u で対応できます。

どちらがいい？

普段、エディターやFinderでファイルを削除するのであれば、git status で確認してから git add -u する方法が分かりやすいと思います。

削除したファイルだけを指定したい場合は、次のようにも書けます。

git add -u -- src/pages/old-page.astro

5. 間違えてファイルを削除した！元に戻すには？

Gitで管理しているファイルなら、削除をコミットする前に復元できます。

例えば、次のファイルを誤って削除したとします。

src/pages/index.astro

削除したことに気づいたら、次のコマンドを実行します。

git restore src/pages/index.astro

ステージしていなければ、通常、Gitのインデックスに保存されている内容から復元されます。

今回のように特殊な名前のディレクトリがある場合

Astroでは、[slug] のように角括弧を使ったファイルやディレクトリ名が登場します。

例えば、

src/pages/[year]/[month]/[day]/[slug]/index.astro

というパスです。

zshでは角括弧がパターンとして解釈される場合があります。

そのため、パスを引用符で囲むと安全です。

git restore -- 'src/pages/[year]/[month]/[day]/[slug]/index.astro'

今回の移行作業でも、このようなルーティングファイルの復元操作を確認しました。

なお、git restore で復元できるのは、基本的にGitで管理されている内容です。

まだ一度もGitへ追加していないファイルを削除した場合は、Gitだけでは復元できません。

6. 間違えて編集したファイルを1つ前の状態に戻したい

ここで重要なのは、何を元に戻したいのかによってコマンドが異なることです。

6-1. まだコミットしていない変更を取り消す

例えば、CSSを修正してみたけれど、元に戻したい場合です。

git restore src/styles/global.css

この操作では、ステージしていない変更が取り消され、通常はインデックスの内容に戻ります。

ただし、変更内容が失われる可能性があるため、実行前に確認してください。

git diff -- src/styles/global.css

6-2. `git add` した変更を取り消したい

コミットする前に、ステージだけ解除したい場合です。

git restore --staged src/styles/global.css

これなら、原則として作業ファイルの変更内容を残したまま、ステージから外せます。

6-3. 直前のコミットを打ち消したい

すでにコミットした変更を打ち消す場合は、

git revert HEAD

という方法があります。

これは、直前のコミットを打ち消す変更を新しいコミットとして記録します。

元のコミット履歴を消さずに修正できるため、履歴を共有している場合にも適した方法です。

ただし、現在の作業内容や変更の重なり方によっては、コンフリクトが発生することがあります。

6-4. プロジェクト全体を直前のコミット状態に戻す

次のようなコマンドもあります。

git reset --hard HEAD~1

これは、現在のブランチを1つ前のコミットへ戻し、インデックスと作業ツリーをその状態に揃えます。

しかし、非常に注意が必要なコマンドです。

未コミットの変更や、現在のコミットからの変更内容が失われる可能性があります。

また、共有済みの履歴を書き換えることにもなります。

初心者のうちは、単に「元に戻したい」という理由だけで使わない方が安全です。

特にAIからこのコマンドを提案された場合でも、何が失われるのか確認してから実行する必要があります。

7. コミット履歴から過去の状態を確認する

過去にどのようなコミットをしたか確認するには、次のコマンドを使用します。

git log --oneline

コミットIDとメッセージを簡潔に表示します。

日時も確認したい場合は、次のようにできます。

git log --date=local --pretty=format:'%h %ad %s'

変更したファイルを含めて確認するなら、

git show --stat HEAD

を使用します。

特定のファイルだけ過去の状態から取り出す

例えば、src/pages/index.astro を直前のコミットのひとつ前の状態へ戻したい場合です。

git restore --source=HEAD~1 -- src/pages/index.astro

これは、指定した過去のコミットから、対象ファイルの内容を作業ツリーへ復元する方法です。

プロジェクト全体を巻き戻すわけではありません。

実行後、内容を確認して必要ならコミットできます。

git diff
git add src/pages/index.astro
git commit -m "Restore previous homepage"

8. 今回つまずいたコミットメッセージの書き方

今回、テキストを修正した際に次のコマンドを実行しました。

git commit -a "edit : text"

しかし、これではエラーになります。

コミットメッセージを指定する -m が抜けていたからです。

正しくは、例えば次のようになります。

git commit -am "Edit text"

-a は追跡済みのファイルの変更と削除を自動ステージします。

-m はコミットメッセージを指定します。

ただし、新しいファイルを追加した場合、-a だけではそのファイルはコミットされません。

初心者のうちは、次のように順番に実行した方が分かりやすいと思います。

git status
git add .
git diff --staged
git commit -m "Edit text"

コミットメッセージは日本語でもいい？

日本語でも問題ありません。

git commit -m "トップページの文章を修正"

英語なら、例えば次のように書けます。

git commit -m "Update homepage text"

英語の学習を兼ねて英語で書くのもよいですが、重要なのは後から変更内容が分かることです。

今回の作業では、次のようなメッセージが候補になりました。

メッセージ	意味
`chore: initialize Astro blog`	AstroブログのGit管理開始
`assets: add WordPress images`	WordPressの画像を追加
`feat: import WordPress content`	WordPressの記事データを取り込む
`feat: redesign homepage`	トップページを新しくデザイン
`feat: migrate posts to content collections`	記事をContent Collectionsへ移行
`refactor: remove legacy post routes`	不要になった旧ルートを削除
`test: verify markdown post creation`	Markdown記事の作成を検証
`chore: prepare for production`	本番公開の準備

これらには実際に使ったものと、作業中に提案されたものが含まれています。すべてがコミット済みの履歴というわけではありません。

実際の履歴は git log で確認する必要があります。

9. 私が実際の作業で使いたいGitの基本手順

Astroで記事やCSSを変更した場合は、次の流れに整理しました。

① 変更したファイルを確認

git status

② 変更内容を確認

git diff

③ 必要なファイルをステージ

git add .

機密情報や不要なファイルを追加していないか注意します。

④ コミット対象を確認

git diff --staged

⑤ Astroをビルドする

npm run build

ビルドが失敗したら原因を確認します。

⑥ 問題がなければコミットする

git commit -m "Update blog"

⑦ 履歴を確認する

git log --oneline

作業途中でも意味のある単位でコミットしておくと、後から変更内容を追いやすくなります。

ビルドするたびにコミットする必要はありませんが、大きな変更をまとめすぎない方が管理しやすいと思います。

10. Gitで失敗したときこそ、まず状態を確認する

Gitには、変更を取り消したり、過去の状態に戻したりするコマンドがいくつもあります。

ただし、似たような目的でも動作は異なります。

例えば、

git restore は指定ファイルの内容を復元する
git restore --staged はステージを解除する
git revert はコミットを打ち消す変更を新たに記録する
git reset --hard は履歴の位置と作業ツリーを変更する

という違いがあります。

よく分からないときは、いきなり復元コマンドを実行するのではなく、次のコマンドで状況を確認します。

git status
git log --oneline -5
git diff
git diff --staged

そして、必要であればAIに結果を渡して、元に戻す方法を確認します。

例えば、次のように依頼できます。

Gitで作業をしています。

間違えてファイルを編集、または削除してしまいました。

現在の git status と git log --oneline -5 の結果を添付します。

未コミットの変更や既存のコミット履歴をできるだけ失わず、安全に元へ戻す方法を教えてください。

まず状態を確認するコマンドから案内してください。

git reset --hard のような破壊的な操作は、ほかの方法で解決できないか確認してから提案してください。

おわりに

Astroでサイトを制作するようになり、ターミナルやGitを使う機会が増えました。

今回の作業では、Gitの管理場所を間違えたり、コミットのオプションを書き間違えたり、不要になったルーティングファイルを整理したりと、さまざまな操作を経験しました。

特に重要だと思ったのは、Gitは単なるバックアップではなく、変更履歴を管理するための仕組みだということです。

正しく使えば、いつどのような変更をしたのか確認でき、必要に応じて過去の状態を取り出せます。

一方で、操作を間違えると変更を失う可能性もあります。

そのため、当面は次のことを意識して使っていこうと思います。

変更前に状態を確認する。

意味のある単位でコミットする。

元に戻すときは、何を戻したいのかを明確にする。

今回の内容は、今後もAstroを使っていく自分自身のための備忘録として残しておきます。

参考資料