Gitブランチを安全に切る基本手順｜記事1本＝1ブランチ運用のすすめ

"main直commitを避けてブランチを切る手順を初心者向けに解説。feature/slug形式でブランチを作り、PR確認後に安全削除するまでの流れをまとめました。"

「mainブランチに直接コミットしていたら、途中で別の修正も混ざってしまった」——Gitを使い始めたころ、そんな経験をした方は多いはずです。

筆者もVercelでサイトを運用し始めた当初、mainへの直commitで何度かデプロイを壊しました。記事1本・機能1つにつき1ブランチを切る習慣をつけてから、PRレビューと本番反映の事故が大幅に減りました。

この記事では、ブランチを安全に作成して削除するまでの基本手順を整理します。

今日の結論

機能・記事ごとにブランチを切ると PR レビューがしやすく、main が汚れない

main直commitは避ける——デプロイ事故の多くはここから起きる

ブランチ削除は「mergeを確認してから」が鉄則。-d が失敗したら原因を調べてから判断する

なぜブランチを切るのか

mainブランチは「本番にそのまま出せる状態」をキープする場所です。作業中の変更や試行錯誤をmainに直接積み上げると、以下の問題が起きやすくなります。

ブランチを切ることで、「この作業の変更だけを確認する」単位が明確になります。

git checkout main
git pull

作業前にmainを最新にしておかないと、古い状態からブランチを切ることになります。差分が積み上がるほど後のマージが複雑になるため、ブランチを切る直前に必ず実行します。

git checkout -b feature/記事slug

ブランチ名は feature/ プレフィックスに記事のslugを続ける形が管理しやすいです。

# 例
git checkout -b feature/git-branch-basic-tips

変更をコミットします。コミットメッセージは「何をしたか」が分かる粒度で書きます。

git add .
git commit -m "add: git-branch-basic-tips 記事追加"

git push -u origin feature/git-branch-basic-tips

-u オプションで上流ブランチを設定します。2回目以降は git push だけで済みます。

GitHub上でPRを作成します。VercelのPRプレビューURLが自動生成されるので、本番と同じ環境で表示を確認してからマージします。

マージ完了後、ローカルのブランチを削除します。

git branch -d feature/git-branch-basic-tips

-d（小文字）はmerge済みのブランチだけを削除します。merge前のブランチには削除を拒否してくれるため、安全です。

error: The branch 'feature/...' is not fully merged.

このエラーが出た場合、リモートへのpushが完了していない、またはマージが反映されていない可能性があります。GitHubのPR画面でマージ済みを確認してから、-D（大文字）での強制削除を検討してください。

ブランチ運用の基本は「mainを常にクリーンに保つ」ことです。記事1本・機能1つにつき1ブランチを切る習慣をつけると、PRレビューの粒度が揃い、デプロイ事故も減ります。

手順をまとめると以下のとおりです。

ブランチ名を後から変更したいケースの手順は別記事で解説予定です（準備中）。

push 前の確認手順（git status・ビルド・ブランチ名など）は「GitHub push前の確認ポイント5つ」でまとめています。

Cursor初心者向けのGit運用全般については、シリーズHub「Cursor初心者トラブル解決シリーズ」もあわせてご覧ください。

免責事項: 本記事はGit・GitHub・Vercelの2026年6月14日時点の仕様にもとづいています。各ツールのコマンド・UI・挙動はアップデートにより変更される場合があります。最新情報は各公式ドキュメントでご確認ください。