Git/GitHub実践ワークフロー — 一人開発でも使うべきブランチ戦略
はじめに
「一人で開発しているし、Git は git add . && git commit だけでいい」――そう思っていた時期もあるかもしれません。しかし、一人開発でも Git を戦略的に使うことで、コードの安全性・開発速度・品質管理 が大幅に向上します。
この記事では、Git の基本コマンドから、一人開発に最適なブランチ戦略、GitHub を活用した PR 運用、CI/CD パイプラインの構築まで、実践的なワークフローを体系的に解説します。
なぜ一人開発でも Git が必要なのか
1. コードのタイムマシン
Git の最大の価値は 任意の時点に戻れる ことです。「昨日の変更で壊れた」「3日前の状態に戻したい」――こうした要望に即座に応えられます。
2. 実験の安全地帯
ブランチを切れば、メインのコードに影響を与えずに新機能の実験ができます。うまくいかなければブランチを捨てるだけ。
3. 変更の意図を記録
コミットメッセージに「なぜその変更をしたか」を記録しておけば、数か月後の自分が「なぜこうなっているのか」を理解できます。
4. デプロイの安全装置
main ブランチを常にデプロイ可能な状態に保ち、feature ブランチからPRを経由してマージする運用にすれば、壊れたコードが本番に出るリスクを大幅に低減できます。
5. AI ツールとの相性
Claude Code のような AI コーディングエージェントは、Git と連携してブランチ作成やPR作成を自動化できます。Git の運用が整っていれば、AI の恩恵を最大限に受けられます。
基本コマンド
リポジトリの初期化とクローン
# 新規リポジトリを作成
git init
# 既存リポジトリをクローン
git clone https://github.com/username/repo.git
# 特定のブランチだけクローン
git clone -b main --single-branch https://github.com/username/repo.git日常的に使うコマンド
# 変更状態を確認
git status
# 差分を確認（ステージング前）
git diff
# 差分を確認（ステージング後）
git diff --staged
# ファイルをステージング
git add file.ts
git add src/components/
# 全ファイルをステージング（注意して使う）
git add .
# コミット
git commit -m "feat: ユーザー認証機能を追加"
# リモートにプッシュ
git push origin feature/auth
# リモートの変更を取得・統合
git pull origin main変更を一時退避する
作業途中で別のブランチに切り替えたいときに使います。
# 変更を退避
git stash
# 退避した変更を復元
git stash pop
# 退避リストを確認
git stash list
# 特定の退避を復元
git stash apply stash@{1}履歴の確認
# コミット履歴を確認
git log --oneline --graph
# 特定ファイルの変更履歴
git log --oneline -- src/utils/auth.ts
# 誰がいつ変更したか（行単位）
git blame src/utils/auth.tsブランチ戦略: GitHub Flow
一人開発に最適なブランチ戦略は GitHub Flow です。Git Flow のように複雑なブランチ構造は不要で、シンプルな2層構造で運用します。
GitHub Flow のルール
mainブランチは常にデプロイ可能 な状態を保つ- 新しい作業は
mainから feature ブランチ を作成して始める - feature ブランチで作業し、こまめにコミット する
- 作業が完了したら Pull Request を作成する
- PR のレビュー（またはセルフレビュー）後に
mainに マージ する
実際のフロー
# 1. main を最新にする
git checkout main
git pull origin main
# 2. feature ブランチを作成
git checkout -b feature/add-user-api
# 3. 作業してコミット
git add .
git commit -m "feat: ユーザーAPIのルーティングを追加"
git add .
git commit -m "feat: バリデーションを追加"
# 4. リモートにプッシュ
git push -u origin feature/add-user-api
# 5. GitHub で PR を作成してマージ
# 6. ローカルの main を更新
git checkout main
git pull origin main
# 7. マージ済みブランチを削除
git branch -d feature/add-user-apiブランチ名の規約
ブランチ名に一定のルールを設けることで、何の作業かが一目でわかります。
| プレフィックス | 用途 | 例 |
|---|---|---|
feature/ |
新機能 | feature/add-user-api |
fix/ |
バグ修正 | fix/login-error |
refactor/ |
リファクタリング | refactor/auth-module |
docs/ |
ドキュメント | docs/api-reference |
chore/ |
雑務（設定変更等） | chore/update-deps |
Pull Request（PR）の運用
一人開発でも PR を使う理由
- 変更のレビュー単位 が明確になる
- CI/CD が自動実行 され、壊れたコードのマージを防げる
- 変更履歴 がPR単位で追跡できる
- AI ツール にPRのレビューを依頼できる
PR テンプレート
GitHub リポジトリに .github/PULL_REQUEST_TEMPLATE.md を作成すると、PR作成時にテンプレートが自動挿入されます。
## 概要
<!-- 何を変更したか、なぜ変更したか -->
## 変更内容
- [ ] 新機能
- [ ] バグ修正
- [ ] リファクタリング
- [ ] ドキュメント
## テスト
<!-- テスト方法・確認事項 -->
## 影響範囲
<!-- この変更が影響する箇所 -->セルフレビューのチェックポイント
一人開発では自分でレビューすることになります。以下の観点でチェックしましょう。
- 不要な変更が含まれていないか — デバッグ用の
console.logや、関係のないフォーマット変更 - テストは通るか — CI が通ることを確認
- セキュリティ — APIキーのハードコードや、認証のバイパスがないか
- パフォーマンス — N+1クエリや、不要なループがないか
- エッジケース — null チェック、空配列、境界値の処理
GitHub Actions で CI/CD を構築する
基本的な CI ワークフロー
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 22
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Lint
run: npm run lint
- name: Type check
run: npm run type-check
- name: Test
run: npm run test
- name: Build
run: npm run buildCD（自動デプロイ）の追加
main にマージされたら自動でデプロイするワークフローの例です。
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 22
cache: 'npm'
- name: Install and build
run: |
npm ci
npm run build
- name: Deploy to Cloudflare Pages
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
command: pages deploy dist --project-name=your-projectブランチ保護ルール
GitHub の Settings > Branches から、main ブランチに保護ルールを設定します。
- Require a pull request before merging — 直接コミットを禁止
- Require status checks to pass — CI が通らないとマージ不可
- Require branches to be up to date — マージ前に最新の main を取り込むことを強制
一人開発でも、これらのルールを設定しておくことで「うっかり壊す」事故を防げます。
.gitignore の設定
プロジェクトの種類に応じた .gitignore の例です。
Node.js プロジェクト
# 依存関係
node_modules/
# ビルド出力
dist/
.output/
# 環境変数（絶対にコミットしない）
.env
.env.local
.env.*.local
# エディタ
.vscode/settings.json
.idea/
# OS
.DS_Store
Thumbs.db
# ログ
*.log
npm-debug.log*
# テスト
coverage/Python プロジェクト
# 仮想環境
venv/
.venv/
__pycache__/
*.py[cod]
# 環境変数
.env
# IDE
.vscode/
.idea/
# ビルド
dist/
build/
*.egg-info/重要: .env は絶対にコミットしない
APIキーやシークレットが含まれる .env ファイルは、.gitignore に追加するだけでなく、リポジトリに一度でもコミットしていないか を確認しましょう。一度コミットしてしまうと、履歴から完全に削除するのは困難です。
# .env がコミット済みか確認
git log --all --full-history -- .env
# もし出力があれば、キーのローテーション（再発行）を強く推奨コミットメッセージ規約
Conventional Commits
コミットメッセージに一定のフォーマットを設けることで、変更履歴の可読性が大幅に向上します。広く使われている Conventional Commits を採用するのがおすすめです。
<type>: <description>
[optional body]
[optional footer(s)]type の種類
| type | 用途 | 例 |
|---|---|---|
feat |
新機能 | feat: ユーザー認証機能を追加 |
fix |
バグ修正 | fix: ログインエラーを修正 |
docs |
ドキュメント | docs: README にインストール手順を追加 |
style |
フォーマット | style: ESLint の警告を修正 |
refactor |
リファクタリング | refactor: 認証モジュールを分割 |
test |
テスト | test: 認証APIのユニットテストを追加 |
chore |
雑務 | chore: 依存パッケージを更新 |
ci |
CI設定 | ci: GitHub Actions にデプロイステップを追加 |
良いコミットメッセージの例
# 良い例: 何をしたかが明確
git commit -m "feat: パスワードリセット機能を追加"
git commit -m "fix: 日本語入力時にバリデーションが誤動作する問題を修正"
git commit -m "refactor: APIクライアントをaxiosからfetchに移行"
# 悪い例: 何をしたかわからない
git commit -m "update"
git commit -m "fix bug"
git commit -m "WIP"コミットの粒度
1つのコミットには 1つの論理的な変更 を含めるのが理想です。
- 機能追加とバグ修正を同じコミットに含めない
- リファクタリングと新機能追加を分ける
- 「動く状態」でコミットする（ビルドが通る状態）
便利なテクニック
Git エイリアス
よく使うコマンドを短縮できます。
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.lg "log --oneline --graph --all"# 使用例
git st # git status
git co main # git checkout main
git lg # グラフ付きログ間違いを取り消す
# 直前のコミットメッセージを修正
git commit --amend -m "fix: 正しいメッセージ"
# ステージングを取り消し（変更は保持）
git restore --staged file.ts
# ファイルの変更を破棄
git restore file.ts
# 直前のコミットを取り消し（変更は保持）
git reset --soft HEAD~1特定のコミットだけ取り込む
# 別ブランチの特定コミットを取り込む
git cherry-pick abc1234タグでリリースを管理
# タグを作成
git tag v1.0.0
# アノテーション付きタグ
git tag -a v1.0.0 -m "初回リリース"
# タグをプッシュ
git push origin v1.0.0GitHub リポジトリの設定ベストプラクティス
README.md
プロジェクトの「顔」です。以下の内容を含めましょう。
- プロジェクトの概要
- セットアップ手順
- 使い方
- ライセンス
ラベル管理
Issue や PR にラベルを付けることで、管理が楽になります。
bug— バグ報告feature— 新機能リクエストpriority: high— 優先度高good first issue— 初心者向け
GitHub Releases
タグと連動してリリースノートを作成できます。変更内容をまとめて公開する際に便利です。
まとめ
一人開発であっても、Git/GitHub を戦略的に使うことで開発の安全性と効率は大きく向上します。
| ポイント | 内容 |
|---|---|
| ブランチ戦略 | GitHub Flow（main + feature ブランチ） |
| PR 運用 | セルフレビュー + CI 必須 |
| CI/CD | GitHub Actions で lint → test → build → deploy |
| コミット規約 | Conventional Commits でメッセージを統一 |
| セキュリティ | .env は絶対にコミットしない |
最初は面倒に感じるかもしれませんが、ルールを一度整えてしまえば、あとは自然に運用できるようになります。何より、「main が壊れていない安心感」は、一人で開発しているときこそ大きな支えになります。
