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

「mainに直接コミットしていたら、途中の別修正まで混ざった」Gitを使い始めたころ、そういう経験はよくあります。Cursorでチャットを切り替えながら作業していると、同じことがもっと起きやすいです。

筆者もVercelでサイトを運用し始めた当初、mainへの直commitでデプロイを壊しました。記事1本・機能1つにつき1ブランチにしてから、PRの確認単位が揃い、本番反映の事故は減っています。

この記事では、ブランチを切る理由から、Cursorでの区切り方、作成〜削除の手順、つまずきやすい3点までを通して整理します。Gitの全体チュートリアルにはしません。AgentでPR本文まで任せる手順は、別記事「Cursor×GitHub連携ガイド｜Agentでgh pr createする手順」へ回します。

今日の結論

• 記事・機能ごとにブランチを切ると、PRで見る範囲が1作業に収まる
• 未コミットの編集はブランチではなく作業ツリー側にある。別作業へ移る前に commit するか stash する
• main直commitは避ける。Vercel運用では、mainへのpushが本番反映につながりやすい
• ブランチ削除は merge を確認してから。-d が失敗したら原因を見てから判断する

記事1本＝1ブランチにする理由

mainは「いま本番に出せる状態」を置く場所です。作業中の試行錯誤をmainに直接積むと、次が起きやすくなります。

• 関係のない変更が1つのコミットに混ざる
• PRで何を確認すればよいか分からなくなる
• VercelのPRプレビューが使えない（mainへのpushが即本番になりやすい）

ブランチを切ると、「この作業の差分だけを見る」単位ができます。Cursorで記事を直すときも同じで、ハンズオンの見た目確認と、別記事のリライトを同じブランチに載せない。混ざったPRは、レビューも戻しも重い。

Cursorでの作業の区切り方

Gitのブランチは、どの commit を指すかのラベルにすぎない。いまエディタに出ている未保存・未コミットのファイルは、ブランチごとに分かれません。作業ツリーはリポジトリに1つです。

だから、チャットを変えて main に戻しただけでは、未コミットの差分は消えません。付いていきます。衝突するファイルがあると、切替そのものが失敗することもあります。2026年8月14日の操作でも、未コミットのまま別ブランチへ移ると差分が付いていくことを確認しています。

区切りの目安は次です。

1. いまの作業を commit する（続きを同じブランチでやる前提）
2. まだ commit したくないときだけ stash する（一時退避）
3. そのあと main を最新化して、次の作業用ブランチを切る

ローカルに commit してあれば、同じ PC では GitHub に上げていなくても、元のブランチへ戻れます。GitHubへの push は、PRを出すときと、別マシンや故障への保険です。電源オフや Cursor を閉じただけでは、ローカルの commit は消えません。

stash の中身の確認と戻し方は「git stash popで元に戻せる理由と使い方」にまとめています。本記事では、切替の前に退避が必要かどうかだけ押さえます。

手順（ブランチ作成から削除まで）

1. mainを最新化する

git checkout main
git pull --ff-only

作業前に最新化しておかないと、古い main からブランチを切ることになります。あとでマージが複雑になるので、ブランチを切る直前に実行します。--ff-only は、想定外のマージコミットを作らずに取り込む指定です。

2. ブランチを作成する

git checkout -b feature/記事slug

名前は feature/ のあとに記事の slug を続ける形が追いやすいです。

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

3. 作業・コミットする

変更を commit します。メッセージは「なぜその変更をしたか」が後から読める粒度にします。

git add .
git commit -m "feat: git-branch-basic-tips に Cursor での区切りを追記"

ここで別チャットの作業へ移りたくなったら、未コミットのまま checkout しない。先に commit するか、stash します。

4. リモートにpushする

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

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

5. PRを作成してプレビューを確認する

GitHub上でPRを作成します。VercelのPRプレビューURLが付く運用なら、本番相当の表示を見てからマージします。Cursor Agent に gh pr create を頼むときの依頼の型は、GitHub連携ガイドを見てください。トークンの実値は書きません。

6. mergeを確認してからブランチを削除する

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

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

-d（小文字）は merge 済みのブランチだけを消します。merge前のブランチは削除を拒否します。

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

この表示が出たら、リモートへの push 漏れか、マージがまだのことが多い。GitHubのPR画面でマージ済みを確認してから、-D（大文字）の強制削除を検討してください。

つまずきやすい3点（stash・ブランチ名・PR前）

未コミットのまま切り替える

別作業のブランチへ移るとき、未コミットのファイルが付いてきます。これはブランチ分けが足りないのではなく、作業ツリーが共有されているためです。

• 残したい作業なら、そのブランチで commit する
• commit したくない途中状態なら git stash push -u で退避し、戻るときに git stash pop

stash を常用しなくてよいケースもあります。先に WIP commit しておけば、切替は git checkout だけで足ります。

ブランチ名が作業とずれる

feature/slug にしておくと、PRタイトルも履歴も後から追いやすい。一時確認用の wip/... を本番向けのリライトと同じブランチに載せない。公開用の差分と、まだ出さない検証は分けます。

PRを出す前に確認しない

push の直前に、変更ファイル・今いるブランチ・ビルドを見ます。手順の詳細は「GitHub push前の確認ポイント5つ」です。ここを飛ばすと、関係ないファイルがPRに混ざります。

チェックリスト

手順の骨格は変わりません。main を最新化してブランチを切り、commit し、PRで見て、merge を確認してから消す。Cursorで複数チャットを並行するときは、その前に 未コミットを残さない ことだけ足します。

ブランチ名を後から変えたい場合の手順は、本記事の範囲外です（準備中）。

push 前の確認は GitHub push前の確認ポイント5つ、AgentでPRを作る手順は Cursor×GitHub連携ガイド をどうぞ。シリーズの入口は「Cursor無料版はどこまで使える？実際に上限到達まで使った記録と制限」です。

本記事の内容は執筆時点（2026-08-14）の Git・GitHub・Vercel・Cursor の操作感に基づきます。コマンドやUIは変わることがあるため、重要な判断は各公式ドキュメントで確認してください。