blueです。
前回はGitとGitHubの理解をしました。
Gemini CLIを使えば、「ブランチを切って」「コミットして」「プッシュして」と日本語で指示するだけでGit操作ができます。
ただ、こんな疑問が残りませんか？
「操作は完了したと言われたけど、GitHubのブラウザ画面のどこを見ればいいのか分からない」
この記事では、作業の流れに沿って、GitHubのブラウザ画面で「どこに何が表示されるか」を順番に解説します。
【用語】リポジトリとは何か
操作の説明に入る前に、一つだけ言葉を確認します。
「リポジトリ（Repository）」とは、一言で言うと「プロジェクトごとの大きなフォルダ」だと思ってください。
単にファイルを入れるだけでなく、「誰が、いつ、どこを書き換えたか」という歴史（記録）がすべて保存されているのがリポジトリです。
nonpro-sandbox というリポジトリなら、「ノンプロ研の砂場プロジェクト専用のフォルダ」という意味になります。
STEP.0 まずリポジトリを開く
- ブラウザで
https://github.comを開きます。 - 画面の左側に
Top repositories（よく使うリポジトリ一覧）が表示されています。 目的のリポジトリ名（例：plannauts/nonpro-sandbox）をクリックします。 - ファイル一覧が見えるリポジトリのTOP画面が開けばOKです。
STEP.1 Issueで「自分のやること」を確認する
作業を始める前に、自分に割り当てられたIssue（タスク）を確認します。
リポジトリのTOP画面、上部に横並びのタブがあります。
[<> Code] [Issues] [Pull requests] [Actions] ...
この中の [Issues] をクリックします。
⚠️ 注意：2つの [Issues] を間違えない！ GitHubを開いてすぐの画面（ログイン直後）の左サイドバーにも [Issues] があります。
こちらは自分が関わる全プロジェクトのIssueが混ざって表示されるので使いません。 必ず、リポジトリに入ってから上部タブの [Issues] を使ってください。
Open と Closed の違い
Issue一覧の上部には、[Open] と [Closed] の2つのタブがあります。
- [Open]：まだ作業中・未完了のIssueが表示されます。通常はこちらを確認します。
- [Closed]：完了（Close）されたIssueが表示されます。
自分の担当Issueが [Open] に見当たらない場合は、 [Closed] タブを確認してみてください。 すでに完了扱いになっている可能性があります。
STEP.2 ブランチを切り替えてファイルを確認する
「ブランチを切って」とGemini CLIに指示したあと、そのブランチをGitHubで確認する方法です。
- 上部タブの [<> Code] をクリックします。
- ファイル一覧の左上にブランチ名のボタンがあります。 （初期状態では
mainまたはmasterと表示されています） - そのボタンをクリックすると、ブランチ一覧と検索窓が出てきます。
- 自分の作業ブランチ名（例：
feat/issue-26-boardgame）を選択します。 - ボタンの表示が選んだブランチ名に変われば切り替え完了です。 ファイル一覧が更新されます。
STEP.3 プッシュした内容を確認する
「プッシュして」と指示したあと、本当にGitHubに届いているか確認する方法です。
- [<> Code] タブのファイル一覧で、 右上あたりに
〇〇 Commits（時計のアイコン付き）が表示されています。 - そこをクリックすると、コミット（セーブ）の履歴一覧が新しい順に並びます。
- 一番上に自分のコミットメッセージが表示されていれば、プッシュは完了しています。
STEP 4. プルリクエストを確認する
作業が完了したら「本編（main/master）に取り込んでください」とチームに依頼します。
- 上部タブの [Pull requests] をクリックします。
- そこをクリックすると、プルリクエストの履歴一覧が新しい順に並びます。
- 一番上に自分のプルリクエストメッセージが表示されていれば、プルリクエストは完了しています。
STEP.5 プルリクエストの画面を読む
プルリクエストを作成すると、その画面でチームのやりとりが確認できます。 「今、自分のPRはどういう状態なのか？」を判断する見方を解説します。
レビューの状態を確認する
プルリクエストページの下部に、レビューの状態がまとめて表示されます。
① 修正を求められている場合
Changes reviewed
1 change requested by reviewers with write access.
これは「レビュアーから修正のリクエストが来ている」状態です。 画面上部のコメントを読んで、指定された修正を行い、再度プッシュしましょう。
⚠️ この状態のままでは [Merge pull request] は押してはいけません。 修正してプッシュすると、自動的にPRに反映されます。
② マージできる状態の場合
✅ No conflicts with base branch
Merging can be performed automatically.
この緑のチェックマークが出ていれば、技術的にはマージ（合流）できる状態です。
[Merge pull request] は押していいの？
押してよい条件は次の2つが揃っている時です。
- レビュアーから「承認（Approve）」をもらっている
- 上記の「No conflicts with base branch」が表示されている
チームによってはレビュアーがマージするルールになっている場合もあります。 迷ったら「マージしてもいいですか？」とチームに確認するのが確実です。
まとめ
操作の流れ（早見表）
| ステップ | 場所 | 操作 |
|---|---|---|
| 0 | 左サイドバー Top repositories | リポジトリを開く |
| 1 | 上部タブ [Issues] | 自分の担当Issueを確認する（OpenとClosedに注意） |
| 2 | ファイル一覧左上 ブランチボタン | 自分の作業ブランチに切り替える |
| 3 | ファイル一覧右上 Commits | プッシュが届いているか確認する |
| 4 | 上部タブ [Pull requests] | PRを作ってチームに合流を依頼する |
| 5 | PRページ下部 レビュー状態 | 修正依頼 or 承認を確認してマージする |
この流れを1サイクル経験すれば、画面の見方は自然と身についてきます。 「操作はAIに任せて、確認はブラウザで」 — これだけ覚えておけば大丈夫です。
コメント