はじめに

この記事では「Issue → ブランチ → PR → マージ → クリーンアップ」までを、なぜ・どうやっての両面に注目しながら書こうと思います。

個人開発でもIssueを作成することは有効であると感じました。頭の中を整理し、タスクをやること・やったこと・次にやることを明確化することで、次何やれば良いんだっけ？を減らすことができたと思ってます。
Issueは迷子にならないための地図みたいなものですね。

なぜ個人開発でもIssue から始めるのか

やること／やったことを整理できる
何を優先するか決めやすい
後から状況を思い出せる
週ごとに振り返りやすい
変更履歴が残る
ブランチ名の付け方を統一できる

結論: 「Issueを作ってから実装」が最も衝突が少なく、振り返り可能性も高い。

1. Issue作成からブランチ作成-CLI版

※GUIでも作成可能ですが、今回はCLIで作成する工程を書きます

# 基本的なIssue作成
gh issue create --title "ユーザー退会機能の実装" --body "退会ボタンと確認ダイアログを実装する"

# より詳細なIssue作成（複数行のbody）
gh issue create \
  --title "レスポンシブ対応の実装" \
  --body "$(cat <<'EOF'
## 実装内容
- モバイル画面での表示最適化
- タブレット画面でのレイアウト調整
- デスクトップでの余白調整

## 受け入れ条件
- [ ] モバイル（375px以下）で適切に表示される
- [ ] タブレット（768px以下）で適切に表示される
- [ ] 既存機能が正常に動作する
EOF
)"

# ラベルと担当者を指定してIssue作成
gh issue create \
  --title "バグ修正: ヘッダーのオーバーフロー" \
  --body "モバイル画面でヘッダーが崩れる問題を修正" \
  --label bug \
  --label priority-high \
  --assignee @me

Issue番号の確認

# 最新のIssueを確認
gh issue list --limit 5

# 特定のIssueの詳細確認
gh issue view 15

# 作成したIssueをブラウザで開く
gh issue view 15 --web

ブランチ作成（Issue番号を含める）

# 現在のブランチから新しいブランチを作成
git switch -c feature/15-user-account-deletion

# mainブランチから最新の状態でブランチ作成
git switch main
git pull origin main
git switch -c feature/15-user-account-deletion

# 用途に応じた命名の例
# feature/15-user-account-deletion  # 新機能
# fix/16-header-overflow           # バグ修正
# chore/17-ci-cache-optimization   # CI/CD改善
# docs/18-api-documentation        # ドキュメント更新

2. 実装→コミット→プッシュ

git add -A
git commit -m "feat: 退会機能の実装 (#15)"
git push origin feature/15-account-deletion01

3. PR作成のタイミング

原則、機能が完成した時点でPRを作成する
本文に Closes #15 を入れると、マージ時にIssueが自動クローズされる
※ #15はIssue番号

gh pr create \
  --title "退会機能の実装" \
  --body "Closes #15\n\n- 退会処理の実装\n- 確認ダイアログ追加\n- 単体テスト整備"

4. レビュー→マージ

# PRがマージされたらローカルを更新
git switch main
git pull origin main

5. クリーンアップ（ブランチ削除）

# ローカル削除
git branch -d feature/15-account-deletion01
# リモート削除
git push origin --delete feature/15-account-deletion01

ブランチを残しすぎると振り返った時に迷子になりやすいです。必要ならタグやコミットからいつでも復元可能で削除するのが良いと感じてます。

削除判断のチェックリスト

迷ったら次で確認。

ブランチはPRでマージ済みか（git branch --merged）
リモートに存在するか（git branch -r）
テスト・Fix系など、一時目的のブランチか

コマンド例

# マージ済みのローカルブランチを一覧
git branch --merged

# リモートブランチの確認
git branch -r

# ローカル削除
git branch -d feature/completed-feature

# リモート削除
git push origin --delete feature/completed-feature

スニペット集

# 新規ブランチを作って切り替え
git switch -c feature/15-account-deletion01

# 作業のスナップショット
git add -A && git commit -m "feat: 実装 (#15)"

# PR作成
gh pr create --title "機能の実装" --body "Closes #15"

# main最新化 → 作業ブランチ削除
git switch main && git pull origin main
git branch -d feature/15-account-deletion01

まとめ

まずIssueで「目的・完了条件」を認識してから着手する
ブランチ名にIssue番号を入れて可観測性を高める
PR本文の Closes #<番号> でクローズを自動化する→任意
マージ後はブランチを整理して、迷子を防ぐ
個人開発でもIssueを活用して認知負荷を下げる（やること・やったこと・次にやることが明確になる）