第8章：よくある質問

この章は、「今すぐ手元で困っていること」 を先に探すページです。ワークフローの全体像は第5章を見てください。

アカウントと組織

Q. GitHub アカウントは会社用と個人用、どちらを使えばよい？

制作業務では、組織 hokuto-com に招待されたアカウント1つ を使います。個人の練習用リポジトリと混ぜても構いませんが、案件のコードは必ず組織側に置きます。プライベートな趣味リポジトリを組織へ移す必要はありません。

Q. 招待メールが届かない

迷惑メールフォルダを確認する
GitHub にログインした状態で https://github.com/hokuto-com を開き、保留中の招待が出ていないか見る
それでも無ければ、オーナーに「招待し直してほしい」と伝える（メールアドレスの打ち間違いがほとんどです）

Q. 2FA（二要素認証）を求められた

組織のセキュリティ設定です。パスワードのほかに、スマホアプリ（Google Authenticator や 1Password など）の6桁コードが必要になります。

機種変更前に、リカバリーコードをパスワードマネージャーへ保存する
ロックアウトしたら、オーナーでは解除できません。GitHub サポートとリカバリーコードが必要です

Q. リポジトリが見えない / 404 になる

権限が付いていません。自分のがそのリポジトリに追加されているか、オーナーへ確認してください。URL の打ち間違い（組織名 hokuto-com を忘れている）もよくあります。

Q. Cloudflareで2段階認証を設定したい

Googleアカウントでログインしている状況では、Cloudflareのパスワードが設定されていないため設定を完了させることができません。そのため、まずはCloudflareのパスワードを設定する必要があります。

ブラウザで以下の専用URLに直接アクセスします。 👉 https://dash.cloudflare.com/forgot-password
Googleアカウントと同じメールアドレスを入力し、「送信（Send）」をクリックします。
届いたメールの指示に従ってパスワードを新規作成します。
パスワード設定完了後、ログインして「マイプロファイル」 > 「認証」から Google Authenticator（2FA）を設定できます。

最初のセットアップ

Q. 2回目以降、同じ案件の作業を再開するときは？

もう一度クローンする必要はありません。Cursor の ファイル＞フォルダーを開く から、前回保存したフォルダを開きます。

Mac: ~/Cursor/案件名
Windows: C:\Cursor\案件名

開いたら、左下の同期アイコンで最新の main を取り込んでから作業します。

Q. クローンとフォークの違いは？

操作	意味	このチームでは
Clone	組織のリポジトリを自分の PC へコピーする	これを使う
Fork	他人のリポジトリを自分のアカウントに複製する	使わない（社内案件は全員が同じ組織リポジトリを触る）

画面の Fork ボタンは押さないでください。

Q. HTML+CSS 納品用テンプレートの使い方は？

画像は src/images/ に置き、HTML からは ./images/ファイル名 で参照します。npm run build のあと、dist/ 一式を渡せば納品できます。

コマンド	意味
`npm run dev`	ブラウザで確認しながら編集する（保存すると自動更新）
`npm run build`	納品用ファイルを `dist/` に書き出す
`npm run preview`	書き出した納品物をローカルで確認する

ブランチと最新化

Q. 最新のコードを他のメンバーから取り込みたい

Cursor 左下の 同期アイコン（回転する矢印） をクリックするか、Agent に「最新の main を取り込んで」と指示します。作業ブランチにいるときは、先に main を最新にしてから、自分の枝へ main を取り込む必要があります。迷ったら Agent に「main の最新をこの作業ブランチにも反映して」と頼んでください。

Q. `main` のまま作業してしまった

まだコミットしていなければ:

変更はそのまま残し、左下から 新しいブランチの作成 をする
ブランチを切った瞬間、今の変更はその新しい枝側へ付いていきます
その枝でコミットしてプッシュする

すでに main にコミットしてしまった場合は、自分で直そうとせず エンジニアかオーナーに共有してください。Rulesets が有効なら、そもそも main へプッシュできずエラーになります。そのときはエラーメッセージをそのまま共有すれば十分です。

Q. ブランチ名を間違えた

GitHub 上で枝をリネームするか、正しい名前の枝を切り直して変更を載せ替えます。既に PR がある場合は、PR を閉じずに枝名だけ変えると URL が変わることがあるので、レビュアーに一言共有します。迷ったら Agent に「ブランチ名を feat/正しい名前 に変更して」と頼んでください。

Q. 作業ブランチがたくさん残っている

マージ済みの枝は、GitHub 側で自動削除される設定にしています。自分の PC に残った古い枝は、次の作業前に main へ戻してから削除して構いません。未マージの作業がある枝だけ残します。

コミットとプッシュ

Q. コミットとプッシュの違いは？

コミット: 自分の PC 上の「保存ポイント」。まだ他の人には見えません
プッシュ: その保存ポイントを GitHub へ送る操作。PR や Preview の材料になります

コミットしただけで「共有した」と思わないでください。ソース管理の 同期 / 公開 まで行います。

Q. コミットメッセージは日本語でよいか

日本語で問題ありません。 先頭の種類だけ英語に揃えます（例: feat: お知らせ一覧のカード実装）。「直した」「更新」だけは、後から見た人が分からないので避けます。

Q. env ファイルを間違えて GitHub に送ってしまった

チャットで「消した」と済ませない
すぐにオーナーへ共有する（履歴に残っているため、ファイルを消すだけでは不十分です）
漏れた API キーは 無効化して再発行する
Cloudflare / microCMS 側の値も新しいキーに差し替える

以降のコミットで .env を除外できているかは、ソース管理ビューで確認します。

Q. プッシュしたら「rejected」や「protected branch」と出た

main へ直接送ろうとしている状態です。正しい手順は次です。

作業ブランチに切り替える（または新規作成する）
そちらへコミットする
作業ブランチをプッシュする
PR を作る

Rulesets は故障ではなく、本番を守るための停止です。

Pull Request とレビュー

Q. Issue と Pull Request の違いは？

	Issue	Pull Request
たとえ	依頼票	確認票
中身	「何をしたいか」	「そのための具体的な変更」
必要なもの	文章と画像で足りる	作業ブランチのコードが必要
終わるとき	`closes #番号` 付きでマージされると自動クローズ	Squash and merge する

先に Issue、あとから PR、の順が原則です。ごく小さな修正でも、Issue を省略するなら PR 本文に「背景」を1行書きます。

Q. PR を出したが Preview URL が付かない

数分待ってもコメントが無いときは、次を確認します。

Cloudflare Pages がそのリポジトリと接続済みか（第6章）
初回デプロイが Organization の GitHub App 許可待ちになっていないか
Actions / Cloudflare のビルドが失敗していないか（PR の Checks や Cloudflare ダッシュボード）

ビルド失敗のときは URL が出ません。ログの先頭エラーをエンジニアへ渡してください。

Q. デザイナーはコードを見なくても Approve してよいか

見た目と動きの確認が目的の PR なら、Approve して問題ありません。 Preview URL を PC と実機で見て、Figma 通りなら Approve します。コードの妥当性はエンジニアが別途見ます。反対に、余白やフォントが違うなら Request changes を使います。気になるだけなら Comment でも構いません。

Q. レビューで直したあと、もう一度お願いするには？

指摘どおり直してコミットし、同じ枝へプッシュする（新しい PR は作らない）
直した内容を PR の Conversation に短く書く
レビュアーを再度 Reviewers に入れるか、@名前再確認お願いします と書く

Rulesets により、新しいコミットが乗ると前回の Approve は無効になります。再 Approve が必要です。

Q. 「Conversation must be resolved」でマージできない

未解決のレビューコメントが残っています。直したコメントの横にある Resolve conversation を押します。指摘がまだ生きているなら、直してから Resolve します。相手の了解なく Resolve だけするのは避けます。

Q. 自分の PR を自分でマージしてよいか

Approve が1件以上あり、Preview 確認が終わっていれば、実装者自身がマージして構いません。Approve が無い自己マージはしません。

Q. Squash and merge を押すと何が起きる？

作業ブランチ上の細かいコミットが、main 上では 1個のコミット にまとまります。そのあと本番デプロイが走り、closes #12 と書いてあれば Issue が閉じます。作業ブランチは自動削除されます。

間違えてマージした場合は、直ちにオーナー / エンジニアへ共有します。チャットで「なかったことに」はできません。

衝突（コンフリクト）

Q. 「This branch has conflicts」と出た

自分の枝と main が、同じファイルの同じ行を別々に変えた状態です。怖がらず、次の順で解消します。

Agent に「main の最新を取り込んで、コンフリクトを解消して」と頼む
画面に <<<<<<< のような印が出ているファイルを一緒に確認する
「自分の変更を残す / 相手の変更を残す / 両方残す」を決める
解消後にコミットし、PR が緑になることを確認する

デザインの数値と、エンジニアの構造変更が同じファイルでぶつかることが多いです。勝手に片方を捨てず、意図を確認します。

Q. 他の人の作業を上書きしてしまわないか不安

同じファイルを同時に触ると衝突は起きますが、Git が両方の変更を消して片方だけ残す、ということは自動ではしません。 衝突したら必ず確認画面が出ます。不安なときは、Issue で「このファイルを触る」と一声してから着手します。

画面の見方・通知

Q. GitHub の通知が多すぎる

担当しないリポジトリの Unwatch をする
メールは「Participating」（自分が関係したもの）だけにする
レビュー依頼は PR の Reviewers 経由に統一し、関係ない人を Watch させない

ベルアイコンの Inbox で Done にすると、未処理だけが残ります。

Q. `@名前` と Reviewers 指定、どちらを使えばよいか

確認してほしい人が決まっているなら Reviewers です。通知が「レビュー依頼」として届き、Approve するボタンも出ます。会話の中でちょっと聞いてほしいときは @名前 で足ります。

Q. Project のカードと Issue、両方更新するのか

Issue が本体です。Project は見た目のボードなので、Issue に Project を付けておけば、Status を動かしたときに同期されます。スプレッドシートへ二重転記しないでください。

権限と公開

Q. クライアントを GitHub に招待すべきか

原則しません。コードとインフラは制作チームが持ち、クライアントには microCMS など運用画面だけ渡します（第7章）。閲覧だけ必要な場合も、まずは Preview URL と納品物で足りるか確認します。

Q. リポジトリを Public にしてよいか

案件コードは Private です。社内テンプレートやこのガイドラインのように、公開してよいと決めたものだけ Public にします。

用語の超短文まとめ

聞かれたこと	一言で返すなら
Git って何？	変更履歴を付ける仕組み
GitHub って何？	その履歴をチームで共有し、依頼と確認をする場所
ブランチは？	本番を汚さない下書き
Issue は？	やることを1件にした依頼票
PR は？	本番に入れてよいかの確認票
マージは？	下書きを本番原稿に取り込むこと
Preview は？	マージ前にだけ存在する確認用サイト

CursorとGitHub上で「コミット」「プッシュ」「プルリクエスト作成」を行う手順を教えて

ターミナル操作やAIのAgentモードを使わずに行う手順をわかりやすくまとめました。

ステップ1：Cursorで変更内容を「コミット」する

「ソース管理」タブを開く
- 画面の一番左にある縦のツールバー（アクティビティバー）から、**「枝分かれした線に丸がついているアイコン（ソース管理）」**をクリックします（ショートカット: Ctrl + Shift + G または Cmd + Shift + G）。
変更したファイルをステージングする
- 「変更（Changes）」の欄に編集したファイル一覧が表示されます。
- まとめてコミットしたい場合は、「変更」という見出しの右側にある 「＋」（すべての変更をステージ） をクリックします（個別に追加したい場合は各ファイルの右の「＋」をクリック）。
- 変更ファイルが「ステージされている変更（Staged Changes）」に移動します。
コミットメッセージを入力してコミット
- 上部のテキスト入力欄にコミットメッセージを入力します（例: ヘッダーデザインの修正）。
- 入力欄のすぐ下にある青い 「コミット（Commit）」 ボタン（またはチェックマークアイコン）をクリックします。

ステップ2：CursorからGitHubへ「プッシュ」する

ブランチをGitHubへ送信する
- コミットが完了すると、先ほどの青いボタンが 「ブランチの発行（Publish Branch）」 に変わります。これをクリックします。
- ※もしすでに過去にプッシュしたことがあるブランチの場合は、ボタンの表記が 「変更の同期（Sync Changes）」 になっているので、それをクリックします。
クリック後、少し待つと青いボタンの表示が消え、GitHubへのプッシュが完了します。

ステップ3：GitHub（ブラウザ）で「プルリクエスト」を作成する

プッシュが完了したら、ブラウザで作業します。

GitHubのリポジトリページを開く
- ブラウザで対象のGitHubリポジトリ（https://github.com/ユーザー名/リポジトリ名）を開きます。
PR作成ボタンをクリックする
- プッシュ直後であれば、リポジトリのトップページ上部に黄色い枠で以下のような通知が表示されます。
  
  [作業ブランチ名] had recent pushes xx seconds ago
- その右側にある緑色の 「Compare & pull request」 ボタンをクリックします。
- ※もし黄色いバーが出ていない場合は、タブの「Pull requests」を開き、緑色の「New pull request」ボタンをクリックして、比較元に対象のブランチを選択してください。
内容を確認してプルリクエストを作成
- 比較先（base）が本番ブランチ（main など）、比較元（compare）があなたの 作業ブランチ になっていることを確認します。
- タイトルと説明文（変更点など）を入力します。
- 右下の緑色の 「Create pull request」 ボタンをクリックします。

その後の流れ（Cloudflare Pages の自動デプロイ）

プレビュー確認：
プルリクエストを作成すると、GitHubと連携したCloudflare Pagesが自動で検知し、ビルドを開始します。数分待つとPRの画面下部に 「Cloudflare Pages」のチェック項目 が表示され、PR専用の「プレビューURL」が生成されて画面上で確認できるようになります。
本番反映（マージ）：
プレビューで問題がなければ、PR画面の緑色の 「Merge pull request」 → 「Confirm merge」 をクリックします。これで main ブランチに統合され、Cloudflare Pagesの本番環境へ自動デプロイが行われます。