第0章：プロジェクト初期設定とGitHub中心ワークフロー標準手順

Git / GitHub の用語とチームルールの本編は 第5章 です。操作で詰まったときは 第8章：よくある質問 を見てください。

プロジェクトの準備（GitHub 新規リポジトリ作成）

目的に沿ったテンプレートを元に、組織 hokuto-com へ新規リポジトリを作成します。公開範囲は Private にします。

選択肢：モダンフロー（Astro）の場合

1. GitHub で astro-starter-template を開く
2. 緑色の Use this template ＞ Create a new repository を押す
3. Owner が hokuto-com になっていることを確認する
4. Repository name に案件名を入力する（例: client-name-lp）
5. Private を選び、緑色の Create repository を押す

選択肢：従来の HTML+CSS の場合

1. GitHub で html-starter-template を開く
2. 緑色の Use this template ＞ Create a new repository を押す
3. Owner が hokuto-com になっていることを確認する
4. Repository name に案件名を入力する（例: client-name-lp）
5. Private を選び、緑色の Create repository を押す

Cursor へクローンする

1. ブラウザで対象の案件リポジトリを開く
2. 緑色の 「<> Code」 ボタンを押す
3. HTTPS タブが選ばれていることを確認し、表示されている URL の右側にある コピー用アイコン をクリックする
   • （URL の例: https://github.com/hokuto-com/client-lp.git）
4. Cursor を起動する
5. 画面上部のコマンドパレットを開く
   • Mac: Cmd + Shift + P
   • Windows: Ctrl + Shift + P
6. git clone と入力し、Git: クローン (Git: Clone) を選ぶ
7. リポジトリの URL を指定 に、コピーした URL を貼り付けて Enter を押す
8. 保存先を選ぶ（Mac: ~/Cursor/、Windows: C:\Cursor\）
9. 「クローンしたリポジトリを開きますか？」と出たら 開く を押す
10. 「この作成者を信頼しますか？」と出たら はい、作成者を信頼します を選ぶ
11. Agent モードで「必要なパッケージをインストールして、ローカルプレビューサーバーを立ち上げてください。」と頼む
12. http://localhost:4321 が表示されたらブラウザで開き、サイトが出れば準備完了

再開方法、最新化、HTML テンプレートのコマンドは 第8章：よくある質問 にまとめています。

テンプレートが使えないとき（Composer で初期化）

テンプレートリポジトリではなく、空のリポジトリから始める場合だけ使います。通常の案件は上のテンプレート手順を優先してください。

1. フォルダの作成場所
   • Mac: ~/Cursor/プロジェクト名
   • Windows: C:\Cursor\プロジェクト名
   • OneDrive や iCloud などの同期フォルダ配下には置かない（第3章）
2. Cursor でフォルダを開き、Ctrl + I（Mac: Cmd + I）で Composer（Agent モード） を起動する
3. 以下の指示文を実行する

Cursor への指示文（コピー用）：

新規Astroプロジェクトを以下の要件で初期化し、GitHubリモートリポジトリに接続してください。

【要件】
1. Astro + Tailwind CSS + TypeScript + microcms-js-sdk をセットアップ
2. ルート直下にガイドライン標準の「.cursorrules」と「.gitattributes (eol=lf)」を作成
3. 「.env」と「.env.example」を作成（MICROCMS_SERVICE_DOMAIN, MICROCMS_API_KEY の雛形）
4. Gitを初期化し、以下のリモートURLに接続してmainブランチに初期コミットをプッシュ
   リモートURL: [ステップ1でコピーしたURL]

4. 作成されたローカルの .env に、microCMS のキーを入力する

GitHub を中心とした日々の開発ワークフロー

初期設定のあとは、すべての作業が 「Issue → 実装 → PR → Preview 確認 → Squash and merge」 で進みます。用語・画面・Rulesets の詳細は 第5章 です。

┌──────────────────────────────────────────────────────────┐
│ 1. 【GitHub】Issue（タスク）を起票する                     │
│    （例: Issue #12「お知らせ詳細ページのUI実装」）        │
└───────────────┬──────────────────────────────────────────┘
                ▼
┌──────────────────────────────────────────────────────────┐
│ 2. 【Cursor】作業ブランチを作成し、AIに実装させる           │
│    （例: ブランチ名「feat/news-detail」）                 │
│    （コミット: feat: お知らせ詳細ページ実装 closes #12）  │
└───────────────┬──────────────────────────────────────────┘
                ▼
┌──────────────────────────────────────────────────────────┐
│ 3. 【GitHub】Pull Request（PR）を作成する                 │
│    （CloudflareがPRコメント欄に「Preview URL」を自動発行）│
└───────────────┬──────────────────────────────────────────┘
                ▼
┌──────────────────────────────────────────────────────────┐
│ 4. 【確認・検収】Preview URLでデザイン・動作をレビュー    │
│    （ディレクター・デザイナーはURLを開くだけで確認完了） │
└───────────────┬──────────────────────────────────────────┘
                ▼
┌──────────────────────────────────────────────────────────┐
│ 5. 【マージ】Approve 後に「Squash and merge」          │
│    ├─ 本番サイトが全自動で最新化される                   │
│    └─ Issue #12 が閉じ、Project も Done になる         │
└──────────────────────────────────────────────────────────┘

チームメンバーの役割分担

• ディレクター / 進行管理:
  • 修正要望やタスクを GitHub の Issue に登録する
  • コーダーから PR が出たら、Preview URL をブラウザや実機スマホで開いて検収する
  • 問題なければ Approve し、条件を満たしたら Squash and merge する
• デザイナー:
  • Figma の 📱 Designs ページに確定デザインを配置する（Auto Layout 必須）
  • PR の Preview URL を見て、余白やフォント、レスポンシブの意図通りかチェックする
• コーダー / エンジニア:
  • Cursor の Composer に Issue #〇〇 と Figma の URL を渡してコードを生成する
  • コミットメッセージに closes #〇〇 と書いて GitHub へプッシュする
  • コード差分のレビューと、.env が混入していないかの確認をする

 main ブランチ保護ルール（Rulesets）の設定手順＜未設定＞

main ブランチへの直接プッシュ（直接コミット）を禁止し、「必ずプルリクエスト（PR）を経由しないと反映できない状態」 にします。

1. 設定場所: GitHubの 組織（Organization）のトップ ＞ Settings ＞ Rules ＞ Rulesets
2. プルリクエストを必須にする。Require a pull request before merging にチェックを入れます。
   • これを有効にすると、main ブランチへの直接プッシュ（直接編集）が完全にブロック されます。
   • Required approvals（必要な承認数）:
     • チームの運用に合わせて選択します（例: 他のメンバーの承認を必須にするなら 1、小規模で各自がPRを出してPreview確認後にマージできればOKなら 0 でもPR運用が強制されます）。
3. 強制プッシュ（Force push）の禁止。Block force pushes にチェックを入れます。履歴の上書き事故を防ぎます。
4. main ブランチの削除禁止。Restrict deletions にチェックを入れます。
   • 誤操作で本番ブランチが消えるのを防ぎます。
5. 保存して有効化する。ページ一番下の緑色の 「Create」（または「Save changes」）ボタンをクリックします。

✅ 設定後の動作確認

設定が完了すると、以下のように動作が変わります：

1. Cursorから誤って main に直接プッシュしようとした場合:
   • Cursorの画面に remote: Push cannot contain direct changes to protected branch 'main' というエラーが表示され、プッシュが弾かれます（事故が未然に防がれます）。
2. 正しい手順（作業ブランチ → PR → マージ）:
   • feat/xxx ブランチを作成してプッシュ ＞ GitHub上でPull Requestを作成 ＞ Preview URL確認後にマージ、という標準フローでのみ反映できるようになります。