🔍 はじめに
私は個人開発でGitを使い始めたものの、運用方法が分からず試行錯誤の日々でした。そこで、本日Copilotと徹底的に議論しながら「Gitの基本を曖昧にしない」ための整理を行いました。本記事では、Issue単位のブランチ管理、Pull Requestの流れ、自動化のメリットについて学んだ内容を共有します！
🛠 Issueごとのブランチ運用
Issueごとにブランチを作成し、そこに関連する変更をコミットしていくのが一般的な開発フローです。これにより、変更の目的を明確にし、履歴管理がスムーズになります。
ブランチの命名規則
feature/issue-123-add-login # 新機能追加に関するIssue 123のブランチ
-
feature/→ 新機能追加 -
issue-123→ 関連するIssue番号 -
add-login→ 変更内容（ログイン機能追加）
Issue番号を含めることで、「どの課題を解決するブランチなのか」が明確になります。特にチーム開発では、後から振り返る際に非常に便利です。
🚀 Pull Request運用のポイント
1つのIssueに対して1つのPull Requestを作成し、レビューを受けてマージするのが基本的な流れです。
- Issueごとにブランチ作成
- 開発を進めながら複数回コミット（修正を細かく管理）
- Pull Requestを作成し、レビューを受ける
- 修正が必要なら、Pull Request内で追加コミット
- 問題なければメインブランチへマージ
Pull Requestの標準フロー
git checkout -b feature/issue-123-add-login # 新しいブランチを作成し、そのブランチへ切り替える
git commit -m "ログイン画面のデザイン調整" # 変更をコミットする
git push origin feature/issue-123-add-login # 作成したブランチをリモートに送信し、Pull Requestを作成可能にする
🔁 Pull Request後の追加変更
Pull Requestを出した後に同じIssueに関する追加の変更が必要になった場合：
- 未マージの場合 → 既存のブランチに追加コミットして更新
- すでにマージ済みの場合 → 新しいブランチを作成し、新しいPull Requestを作成
git checkout main # ブランチを切り替える
git pull origin main # リモートリポジトリの最新の main を取得して、ローカルの main に統合する
git checkout -b feature/issue-123-fix-login # 新しいブランチを作成し、そのブランチへ切り替える
Pull Requestの更新か、新しいPull Requestを作るかは状況次第！
⚡️ 自動化の導入
Gitの操作をスクリプト化することで手動のコミット＆プッシュ作業を削減できます。
自動コミットスクリプト
git add .
git commit -m "定期コミット"
git push origin main
これをシェルスクリプトにまとめることで、ポチポチ手動でやる手間を削減できます。
さらに、GitHub Actionsを設定すれば、特定のイベントが発生したら自動でコミット＆プッシュなどの設定も可能です。
📌 まとめ
今回の学びを整理すると：
- Issueごとにブランチを作成し、コミットを管理する
- Pull Requestは原則1Issueにつき1回。ただし追加修正が必要なら更新可能
- CUIを活用することでGitの操作がより効率的になる
- スクリプトやGitHub Actionsを使うことでコミット＆プッシュを自動化できる
- 命名規則を統一することでチーム開発でも管理がスムーズになる
Git運用を整理することで、開発の流れをスムーズに進めることができます。
私自身も、このプロセスを整理することで理解がより深まりました。
ぜひ皆さんも試してみて、実際のプロジェクトに活かしてみてください！