GitHub push前の確認ポイント5つ【git statusを最初に習慣化する】

"Cursor＋GitHubで開発する初心者向け。pushの前にgit statusで変更ファイルを確認し、ブランチ・ビルド・リモート先をセットでチェックする習慣を手順とともに解説します。"

「意図しないファイルを push してしまった」「間違ったブランチに push した」——Git を使い始めたばかりの頃は、こういったミスがよく起きます。

push はリモートリポジトリに変更を送る操作なので、一度送った内容を取り消すのは手間がかかります。筆者の経験上、push 前の数十秒の確認が後戻り作業を大幅に減らしてくれます。

この記事では、push 前に筆者が毎回チェックしている5つのポイントをまとめます。

今日の結論

push の最初の一手は git status で変更ファイルの確認

意図しないファイルが含まれていないかを目視する

ビルド成功・ブランチ名・リモート先をセットで確認する習慣をつける

なぜ push 前の確認が必要なのか

Cursor のようなAIエージェントを使っていると、依頼した変更以外のファイルが意図せず編集されていることがあります。そのまま git add . で全ファイルをステージして push すると、関係ないファイルの変更もリモートに送られてしまいます。

git status を先に実行するだけで、どのファイルが変更されているかを一覧で確認でき、こうしたミスの多くを防げます。

git status

変更ファイルの一覧が表示されます。「このファイルは変更した覚えがない」というものが含まれていたら、git diff で差分を確認してから次のステップに進みます。

npm run build

ローカルでビルドが通らない状態で push しても、Vercel のデプロイが失敗します。build 成功を確認してから push するのが基本の順序です。

npm run build の詳しい手順や意義は「push前にnpm run buildを実行すべき理由」で解説しています。

git commit -m "fix: OGP画像のパスを修正"

コミットメッセージは後から履歴を見たときに何を変更したかが分かる内容にします。「update」「fix」だけでは、数週間後に見返したときに意味がわかりません。変更内容を1行で表せる粒度が目安です。

git branch

現在のブランチ名が表示されます。main に直接 push する運用でなければ、作業ブランチ（例: feature/ogp-fix）になっているかを確認します。

git push origin <ブランチ名>

push が完了したら、Vercel の Preview URL を開いて表示崩れやエラーがないかを確認します。問題がなければ本番ブランチへマージします。

これらを習慣にするだけで、「push してからミスに気づく」後追い対応の頻度は大きく下がります。

Cursor を使った GitHub 連携の全体像は「Cursor 無料版で Next.js サイトを作る」シリーズでまとめていますので、あわせてご覧ください。

免責: 本記事は 2026年6月17日時点の情報をもとに執筆しています。Git・GitHub・Vercel・Cursor の仕様は変更される可能性がありますので、最新情報は各公式ドキュメントをご確認ください。