図解でつながる、GitHubの基本

Gitは、変更履歴を扱う仕組み。GitHubは、その履歴を共有し、変更を相談するサービス。 リポジトリは、ひとまとまりのファイルと履歴を管理する単位。「このアプリの作業一式」と考えると入りやすい。[4][6]

上図は「手元で開発し、GitHubを経由してサイトを公開する」構成例。GitHubだけでも編集でき、すべてのリポジトリがサイト公開につながるわけではない。[4][14]

たとえば、動いているダッシュボードに検索を追加したい。いきなり採用済みの版を直す代わりに、mainからadd-searchという作業ブランチを作る。そこで検索を試し、良ければあとで取り込む。[4][5]

main

この説明では「採用済みの本流」として扱うブランチ。特別に壊れなくなる名前ではなく、運用上の役割。

ブランチ

同じプロジェクトに、別の変更の流れを持たせるもの。新しいリポジトリを毎回作るわけではない。

コミット

「検索欄を追加」「絞り込み処理を追加」のように、選んだ変更を履歴の区切りとして残す操作。

ブランチは厳密には、特定のコミットを指す軽い参照。通常はブランチを切り替えると、同じ作業フォルダー内の管理対象ファイルがその版に切り替わる。コミット前の変更はブランチに完全に隔離されたとは限らない。[6][7]

「別の場所」まで作る必要はある？

1つずつ作業するなら、まずは同じフォルダーでブランチを切り替える理解で十分。AIに複数の仕事を並行させる場合には、worktree（ワークツリー）などで作業フォルダーも分ける方法がある。ブランチが「履歴の分かれ道」、worktreeが「実際の作業場所」の違い。[6][19]

ブランチ名は説明のための例。feature/add-searchのように付けてもよい。分けることで守れるのは主にGitで管理する変更履歴であり、本番データベースや外部サービスまで自動的に分離されるわけではない。

次は、add-searchで作った検索機能が、どこまで届いたかを見る。同じ「変更」でも、操作ごとに届く場所が違う。[7][8][11][14]

手元の作業ブランチからGitHubのmainへPRを出すケース。mainに直接Pushする場合や、GitHubのブラウザー上で編集する場合は経路が異なる。[4][11][9]

Pull Request（プルリクエスト）は、あるブランチの変更を、別のブランチへ取り込む提案。PR、プルリクとも呼ぶ。変更の理由、実際の差分、確認結果、やり取りを一緒に残せる。[8]

GitHubのUIを説明のために簡略化したもの。ラベルや配置は表示環境により変わる。PRの向きとレビューの意味は公式資料で確認。[9][10][5][4]

例は「ダッシュボードに検索を追加する」。以下はPRを使う進め方の一例。小さな変更も必ずすべてPRにしなければならない、という意味ではない。[5][4]

1. 最新を受け取る未保存・未コミットの作業を確認してから、手元のmainへGitHub側の更新を取り込む。
2. ブランチを作るadd-searchを作って切り替える。「検索の変更はこの枝で行う」と分ける。
3. 編集・動作確認検索を作って試す。区切りごとに、対象の変更を選んでCommitする。
4. Pushする作業ブランチをGitHubへ送る。この段階でもmainへの取り込みは別。
5. PRを作るadd-search → mainを提案。何を変え、何を確認したかを書く。
6. レビューする差分・チェック結果・実際の画面を確認。必要な修正は同じ枝へCommit・Pushする。
7. マージするよければGitHub側のmainへ取り込む。不要になった作業ブランチは整理できる。
8. 公開・同期を確認公開する案件ならデプロイ結果と公開先を確認。次の作業は手元のmainも更新してから始める。

ブランチ削除で、取り込み済みの機能まで消えるわけではない。PRと取り込み後の履歴は残る。公開処理はGitHubフローそのものとは別の連携。[5][11][14]

PushとPullは「行き」と「帰り」

Gitは、異なる場所への変更なら自動的に統合できることが多い。一方、同じ行を別々に変更した場合や、片方が削除したファイルをもう片方が編集した場合などには、コンフリクト（競合）が起こる。[12]

例：もともと同じ行に 表示件数 = 10 と書いてあった。

この場合、新しい方を自動採用すれば正しい、とは限らない。「何を実現したいか」を確認し、最終的な内容を決めてから統合する。AIに直す作業を頼む場合も、採用したい仕様まで曖昧にしない。[12]

Issue（イシュー）は「何をしたいか・何に困っているか」。PRは「こう変えたので取り込みたい」。 Issueは、要望・不具合・作業の計画や議論に使える。コードの変更そのものではない。[13][8]

番号は説明用。通常はリポジトリ内の番号なので、他のリポジトリの「#12」と同じ案件ではない。IssueとPRは必ず1対1である必要はない。[13]

ChatGPTで相談 → Codexで実装、に当てはめると

相談で決めた内容をIssueに残す → 作業ブランチで実装 → PRで成果を確認 → マージ。 この流れにすると、「頼んだ内容」と「実際に入れようとしている変更」を分けて確認できる。これは本ガイドでの運用例であり、Issueを作っただけで自動的にAIが動く、という意味ではない。

GitHub Desktopで見る場所

originは接続先リポジトリに付く一般的な名前。この構成ではGitHub側を指す。ボタンの表示は状態・バージョンによって変わる。[11][18]

Codexへ頼むなら、作業の終点を明確にする

操作を自分で打つ代わりに頼んでも、どのリポジトリ・どのブランチを・どこまで変えるかは同じ。次はPRで確認してから採用する場合の指示例。接続・認証・権限など、実際に操作できる環境が前提。

このリポジトリの最新mainから、検索追加用のブランチを作って。
検索欄を追加し、差分と動作を確認して、コミット・Push・main宛てのPR作成まで進めて。
既存の未コミット変更や無関係なファイルは巻き込まないで。
マージはせず、PRのURL・変更内容・確認結果を報告して。

変更せず、現在のリポジトリとブランチ、未コミット変更、未Pushのコミット、関連PRの状態、mainへの反映状況を確認して。
公開連携がある場合は、最後のデプロイ結果も分けて報告して。

この例の「マージしない」は、PR確認用の停止位置を示すためのもの。既存のプロジェクトでmainへ直接Pushする運用を採用しているなら、その方針を勝手に置き換える必要はない。

画面で一度試すなら、公式のHello World

GitHub公式の練習は、ブラウザー上でREADMEを変えてPR・マージまで進む内容。プログラムを書く必要も、Gitのコマンドを入力する必要もない。自分の本番アプリではなく、練習用リポジトリで流れを確かめる用途に向いている。[4]

最後に、3つだけ確認

ブランチで分ける → コミットで残す → Pushで送る。
PRで確認する → マージで取り込む → Pullで受け取る。

公開するアプリなら、この流れにデプロイと公開先の確認が加わる。

該当しそうなのは、安野貴博さんの「バイブコーディング超入門講座」第5回と第6回。 ユーザーが見た動画のURLは未指定なので、この2本を有力候補として整理した。[1][2]

調査範囲：動画の公開タイトル・説明欄と、動画を参照する関連記事を確認。動画全編の映像・字幕を直接検証した逐語要約ではない。感想の多数派や評判の広さまでは確認していない。関連記事の説明をそのまま正解とはせず、Git／GitHub／Cloudflareの仕様は以下の一次資料で照合した。本文の図・画面例・操作例はこのガイド用に作成したもの。

本文の根拠

1. 01
   安野貴博の自由研究｜バイブコーディング超入門講座 第5回 ↗

   初心者向けGit & GitHub解説。動画の特定と説明欄の目次を参照。

2. 02
   安野貴博の自由研究｜バイブコーディング超入門講座 第6回 ↗

   Claude CodeでのGit & GitHub実演を扱う回。

3. 03
   大田原正幸｜Git/GitHub 超入門（2026年6月25日） ↗

   第5・6回を参考にして再構成した、直接関連する入門記事。

4. 04
   GitHub Docs｜Hello World ↗

   ブラウザーだけで、ブランチ・コミット・PR・マージを練習する公式入門。

5. 05
   GitHub Docs｜GitHub フロー ↗

   作業ブランチ、変更、PR、レビュー、マージ、ブランチ削除の基本的な流れ。

6. 06
   Pro Git｜Branches in a Nutshell ↗

   ブランチはコミットを指す参照。枝分かれと作業フォルダーの切り替わり。

7. 07
   Git｜git-commit ↗

   コミットは選択した内容の状態を履歴に記録する操作。

8. 08
   GitHub Docs｜Pull requests ↗

   変更提案・差分・議論の場としてのPR。

9. 09
   GitHub Docs｜Creating a pull request ↗

   取り込み先baseと変更元compareの区別。

10. 10
    GitHub Docs｜Pull request reviews ↗

    コメント、承認、変更要求と、レビューの意味。

11. 11
    GitHub Docs｜Syncing your branch in GitHub Desktop ↗

    Fetch origin、Pull origin、Push originと同期。

12. 12
    GitHub Docs｜Merge conflicts ↗

    自動的に統合できない競合と、内容を決める必要性。

13. 13
    GitHub Docs｜About issues ↗

    要望・不具合・タスクを議論し追跡するIssue。

14. 14
    Cloudflare Pages｜Git integration ↗

    GitHubの更新と、ビルド・デプロイの連携。自動デプロイは無効化も可能。

15. 15
    Cloudflare Pages｜Preview deployments ↗

    本番とは別の確認用URL。リポジトリの非公開設定とは別に扱う。

16. 16
    Git｜git-revert ↗

    過去の変更を打ち消す新しいコミットを作る。

17. 17
    GitHub Docs｜Removing sensitive data from a repository ↗

    秘密情報の漏えい時は、ファイル削除だけでなく認証情報の失効・交換が必要。

18. 18
    GitHub Docs｜Committing and reviewing changes in GitHub Desktop ↗

    差分を確認し、コミットする対象を選ぶGUI操作。

19. 19
    OpenAI｜Introducing the Codex app ↗

    AIによる開発と、別の作業場所を使うworktreeの説明。

20. 20
    Git｜git-pull ↗

    リモートの更新を取得し、現在のブランチへ統合する。

21. 21
    Git｜git-fetch ↗

    リモートの履歴を取得する。作業ブランチへの統合とは別の処理。