10以上のプロジェクトをGitHubで管理し、wrangler deployで本番反映する開発フロー
Git（ギット）は、プログラムのソースコードを管理するためのバージョン管理システムです。GitHub（ギットハブ）は、Gitリポジトリをクラウド上でホスティングし、チーム開発を支援するサービスです。
私たち京谷商会では、10以上のプロジェクトをすべてGitHubで管理しています。kyotani-shoukai-api、haishoku-api、nad-api、portal-worker、各クライアントサイトのリポジトリなど、コードの変更はすべてGitで追跡し、npm run deploy（内部的にwrangler deploy）で本番に反映するフローを徹底しています。
この記事では、GitとGitHubの基本を解説しながら、私たちが実際に使っている開発ワークフローを紹介します。
なぜGitが必要なのか — 京谷商会の実体験
Gitを使う前の開発は「index_v2_final_本当に最終版.html」のようなファイル名管理に陥りがちです。京谷商会でも、Git導入前はファイルのコピーで履歴管理をしていた時期がありました。
Gitを使うと、以下のことが可能になります。
- ファイルの変更履歴を記録・管理（いつ、誰が、何を変えたか）
- 過去の任意の時点に戻す（デプロイ後の不具合発見時に即ロールバック）
- 複数人で同時に開発を進める
- 変更の競合（コンフリクト）を解決する
特に私たちが重宝しているのはロールバック機能です。npm run deployでCloudflare Workersにデプロイした後に不具合が見つかった場合、git revertで前のバージョンに戻し、再度デプロイするだけで本番環境を復旧できます。
Gitは2005年にLinuxカーネルの開発者であるLinus Torvaldsが開発し、現在ではソフトウェア開発者の96%以上が使用する標準的なバージョン管理システムとなっています。
GitとGitHubの違い
Gitでできること:
- ローカルでのバージョン管理
- ブランチの作成・マージ
- コミット履歴の管理
GitHubでできること（Gitに加えて）:
- リモートリポジトリのホスティング
- プルリクエスト（コードレビュー）
- Issues（課題管理）
- GitHub Actions（CI/CD）
- プロジェクト管理
- GitHub Copilot（AIコーディング支援）
京谷商会では、GitHubのプライベートリポジトリですべてのプロジェクトを管理しています。APIキーや環境変数などの機密情報は.gitignoreで除外し、Cloudflare Workersのwrangler secret putで別途管理しています。
なお、GitHubの他にもGitLab、Bitbucketなどのホスティングサービスがありますが、GitHubが最も利用者が多く、2024年時点で1億人以上の開発者が利用しています。
Gitの基本概念
リポジトリ（Repository）
プロジェクトのファイルと変更履歴を保管する場所です。
- ローカルリポジトリ: 自分のPC上にあるリポジトリ
- リモートリポジトリ: GitHub上にあるリポジトリ
京谷商会のリポジトリ構成例:
kyotani-shoukai-api/ → メインAPI（[Hono](/dev/glossary/hono) + [D1](/dev/glossary/d1)）
haishoku-api/ → 配食のふれ愛API
nad-api/ → NAD.JP API
portal-worker/ → 18ポータルの配信Worker
shibata-kogyo/ → 柴田工業サイト
wio-construction/ → WIOの工事屋さんサイト
コミット（Commit）
ファイルの変更を記録する操作です。各コミットには以下の情報が含まれます。
- 変更内容（差分）
- コミットメッセージ（変更の説明）
- 作成者
- タイムスタンプ
- 一意のハッシュ値（SHA-1、40文字の16進数）
Git公式ドキュメントのコミットの記録に詳しい解説があります。
ブランチ（Branch）
開発の本流（main）から分岐して、独立した作業を行うための機能です。
main ────●────●────●────●────●
\ /
feature ●────●────●
ステージングエリア（Index）
Gitの特徴的な概念としてステージングエリア（インデックス）があります。git addでファイルをステージングエリアに追加し、git commitでステージングされた変更をまとめてコミットします。この2段階の仕組みにより、変更の一部だけを選んでコミットすることが可能です。
Gitのインストールと初期設定
インストール
- Windows: Git for Windowsをダウンロード。Git BashとGUIが付属
- macOS:
xcode-select --installでXcode Command Line Toolsをインストールすると付属。またはHomebrewでbrew install git - Linux:
sudo apt install git（Ubuntu/Debian）またはsudo dnf install git（Fedora）
初期設定
git config --global user.name "あなたの名前"
git config --global user.email "your@email.com"
git config --global init.defaultBranch main
git config --list
初期設定の詳細はGit公式のFirst-Time Git Setupを参照してください。
京谷商会の開発ワークフロー
1. 開発環境の構成
私たちの開発環境は以下の構成です。
- エディタ: VS Code + Claude Code（AIアシスタント）
- ランタイム: Node.js + npm
- フレームワーク: Hono（API）、React + Vite + Tailwind（ダッシュボード）
- デプロイ: wrangler CLI（Cloudflare Workers）
- データベース: D1（Cloudflare SQLite）
- 言語: TypeScript
2. 基本的な作業の流れ
git pull origin main
git switch -c feature/add-search-api
npm run dev
git add src/routes/search.ts
git commit -m "記事検索APIを追加"
git push origin feature/add-search-api
git switch main
git pull origin main
npm run deploy
git switchとgit restoreについて: Git 2.23以降、git checkoutの機能がgit switch（ブランチ切替）とgit restore（ファイル復元）に分離されました。従来のgit checkoutも引き続き使えますが、目的が明確な新コマンドの使用を推奨します。
**最後のnpm run deploy**がwrangler deployを実行し、Cloudflare Workersに本番反映されます。ビルドからデプロイまで通常30秒以内で完了します。
3. 良いコミットメッセージのポイント
京谷商会では、コミットメッセージに以下のルールを設けています。
- 「何を」「なぜ」変更したかを簡潔に書く
- 1行目は50文字以内を目安に
- 必要に応じて本文で詳細を記載
- Conventional Commitsの形式（
feat:,fix:,docs:等のプレフィックス）も有効
実際のコミットメッセージ例:
feat: 記事検索APIにページネーションを追加
D1のOFFSET/LIMITを使用。1ページあたり20件。
portal-workerの記事一覧ページで使用する。
.gitignoreファイル — 機密情報の保護
Gitで管理する必要のないファイルを指定する設定ファイルです。機密情報の漏洩を防ぐために極めて重要です。
node_modules/
.env
.dev.vars # wranglerのローカル環境変数
*.log
dist/
.wrangler/ # wranglerのローカルデータ
.DS_Store
必ず除外すべきもの:
node_modules/（npmで復元可能）.env・.dev.vars（環境変数・APIキー・シークレット）.wrangler/（ローカルのD1データなど）- ビルド成果物（
dist/） - OS固有のファイル（.DS_Store、Thumbs.db）
GitHubが公開している言語別.gitignoreテンプレート集を参考にすると、プロジェクトに応じた適切な除外設定が作れます。Node.js用テンプレートをベースにCloudflare Workers固有のファイルを追加するのが京谷商会のやり方です。
京谷商会では、APIキーやOAuthトークンはCloudflare Workersのwrangler secret putで管理しています。.dev.varsファイルにローカル用の値を入れてテストし、本番のシークレットはCloudflareのダッシュボードまたはCLIから設定します。
ブランチ戦略
ブランチの作成と切り替え
git switch -c feature/new-header
git switch feature/new-header
git checkout -b feature/new-header
京谷商会のブランチ命名規則
feature/add-search-api → 新機能
fix/article-encoding → バグ修正
refactor/cleanup-routes → リファクタリング
docs/update-readme → ドキュメント更新
GitHub Flow
京谷商会ではGitHub Flowを採用しています。mainブランチは常にデプロイ可能な状態を保ち、すべての変更はfeatureブランチからプルリクエストを経由してマージします。Git Flowのような複雑なブランチモデルは、私たちの規模では過剰なため採用していません。
GitHub Flowの詳細はGitHub公式ドキュメントに解説があります。
プルリクエスト（Pull Request）
プルリクエスト（PR）は、GitHubの最も重要な機能の一つです。ブランチの変更をmainブランチに取り込む前に、変更内容をレビューするための仕組みです。
プルリクエストの流れ
- featureブランチで作業してコミット
- GitHubにプッシュ
- GitHub上でプルリクエストを作成
- コードレビュー（変更内容を確認）
- 修正が必要な場合はコミットを追加
- 承認されたらmainにマージ
npm run deployで本番反映
良いプルリクエストの作り方
- 小さく保つ: 1つのPRで1つの機能・修正に絞る
- 説明を書く: 何を変更したか、なぜ変更したかを記載
- テスト結果を含める: 動作確認の方法や結果を記載
京谷商会ではClaude CodeがPRの作成を支援しています。変更内容の要約とテスト計画を自動生成し、レビュー効率を向上させています。
コンフリクト（競合）の解決
複数人で同じファイルの同じ箇所を変更した場合、マージ時にコンフリクトが発生します。
<<<<<<< HEAD
現在のブランチの内容
=======
マージしようとしているブランチの内容
>>>>>>> feature/other-branch
解決手順:
- コンフリクトが発生したファイルを開く
<<<<<<<、=======、>>>>>>>のマーカーを確認- 最終的に残したい内容に手動で書き換える
- マーカーを削除
git addでステージングし、git commitで解決を記録
VS Codeはコンフリクトの可視化と解決支援のUIを備えており、「Accept Current」「Accept Incoming」「Accept Both」のボタンで直感的に解決できます。
よく使うコマンドまとめ
| コマンド | 説明 |
|---|---|
| `git init` | リポジトリを初期化 |
| `git clone URL` | リポジトリをクローン |
| `git status` | 変更状態を確認 |
| `git add ファイル名` | 特定ファイルをステージング |
| `git commit -m "メッセージ"` | コミット |
| `git push origin branch` | リモートにプッシュ |
| `git pull origin branch` | リモートからプル |
| `git branch` | ブランチ一覧 |
| `git switch -c name` | ブランチ作成・切替 |
| `git merge branch` | ブランチをマージ |
| `git log --oneline` | コミット履歴を表示 |
| `git stash` | 変更を一時退避 |
| `git stash pop` | 退避した変更を復元 |
| `git revert HEAD` | 直前のコミットを取り消し |
| `git restore ファイル名` | ファイルの変更を元に戻す |
| `git diff` | 未ステージの変更を表示 |
| `git diff --staged` | ステージ済みの変更を表示 |
コマンドの詳細な使い方はPro Git（無料でオンライン公開されている公式書籍）が最も信頼できるリファレンスです。
セキュリティとベストプラクティス
機密情報のコミット防止
誤って.envやAPIキーをコミットしてしまうと、GitHubにプッシュした時点で公開されるリスクがあります。一度プッシュした機密情報はGitの履歴に残るため、プッシュ前の防止が最も重要です。
.gitignoreを最初に設定するgit add .ではなく個別のファイルをgit addする習慣をつける- GitHubのSecret Scanningを有効化し、誤ってプッシュされた機密情報を自動検出する
署名付きコミット
コミットの作成者を暗号学的に証明するために、GPG鍵やSSH鍵でコミットに署名できます。GitHub上で「Verified」バッジが表示され、なりすましコミットを防止します。
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
デプロイまでの完全フロー — Git + wrangler
京谷商会の開発では、Gitでのバージョン管理とwranglerでのデプロイが一体化しています。
npm run dev # wrangler dev でローカルサーバー起動
git add src/routes/search.ts
git commit -m "feat: 検索APIのレスポンス形式を統一"
git push origin main
npm run deploy # wrangler deploy を実行
このシンプルさが、Cloudflare Workers + Gitの組み合わせの魅力です。CI/CDパイプラインを組まなくても、コミット → デプロイの流れが自然に習慣化されます。
さらに大規模なプロジェクトでは、GitHub Actionsを使ってmainブランチへのマージをトリガーに自動デプロイを設定することもできます。京谷商会では一部のプロジェクトでこの自動デプロイを導入済みです。
まとめ
GitとGitHubは、現代のソフトウェア開発において必須のツールです。最初は覚えることが多く感じるかもしれませんが、基本的な操作（add → commit → push）を繰り返すうちに自然と身につきます。
京谷商会では10以上のプロジェクトをGitHubで管理し、毎日のようにgit commitとnpm run deployを繰り返しています。この「コード変更 → Git記録 → 本番反映」のサイクルが、18ポータルサイト・7つのAPIの安定運用を支えています。
まずは個人プロジェクトでGitの基本操作に慣れ、次にGitHubでプルリクエストの流れを体験してみてください。Webサイトの表示速度改善やAPI開発のプロジェクトで実践するのが最良の学習方法です。