1ポイント
用語は作業で覚える
GitHub用語は暗記より、Codex作業のどこで使うかに結びつけると理解しやすいです。
まなぶちゃん全部の用語を覚えないとダメ？
GPTガイドくん最初はリポジトリ、ブランチ、コミット、PRだけで十分です。
GitHub basic terms
GitHub基本用語｜リポジトリ・コミット・ブランチ・Pull Request
GitHubで最初につまずきやすい4つの言葉を、コードを書かない人にも分かるように整理します。
このページは非公式の実践ガイドです。GitHubの画面や機能、仕様は変わる可能性があります。最新情報が必要な場合は、提供元が公開している情報も確認してください。
GPTガイドくん
リポジトリ、コミット、ブランチ、Pull Requestを押さえると、Codex作業の報告も読みやすくなります。
まなぶちゃん
英語のまま覚えるより、日本語の意味とセットで理解します。
GitHub用語は4つから覚えると分かりやすい
GitHubには多くの用語がありますが、初心者はまずリポジトリ、コミット、ブランチ、Pull Requestの4つから覚えると理解しやすくなります。
| 用語 | たとえ | 意味 |
|---|---|---|
| リポジトリ | 作業ファイルを入れる箱 | コードやページ素材をまとめて管理する場所 |
| コミット | 変更の記録 | いつ何を変えたかを残すセーブポイント |
| ブランチ | 本体とは別の作業スペース | 本体を直接変えずに試すための分岐 |
| Pull Request | 確認してから取り込む依頼 | 変更を本体へ入れる前に差分を見せる提案 |
- リポジトリを作るファイルを置く場所を用意する
- ブランチを作る本体とは別の場所で作業する
- ファイルを変更するHTMLやCSS、READMEなどを直す
- コミットする変更内容を記録する
- Pull Requestで確認する差分を見てから取り込む
リポジトリとは
リポジトリは、コードやファイルをまとめて管理する場所です。Webサイトなら、HTML、CSS、画像、READMEなどを入れる箱のようなものです。
リポジトリでは変更履歴を残せるため、あとから「どこを変えたか」を確認しやすくなります。チームやAIツールと作業を共有しやすいこともメリットです。
index.html、about/index.html、assets/css/style.css、README.md など。
APIキー、パスワード、SSH鍵、DB接続情報、.envの中身、個人情報、外へ出せない業務情報。
注意 GitHubのリポジトリは便利ですが、外へ出せない情報の保管場所ではありません。public/privateに関係なく、接続情報やログイン情報を置かないようにしてください。
コミットとは
コミットは、変更内容を記録することです。いつ、何を変更したかを残せるので、あとから差分を確認したり、戻す時の目印にしたりできます。
初心者向けに言うと、コミットは作業のセーブポイントです。小さく分けて記録すると、確認しやすく、戻しやすくなります。
| 良いコミット例 | 避けたいコミット例 |
|---|---|
| トップページに初心者向けリンクを追加 | いろいろ修正 |
| 安全ページにNG例を追加 | 全部変更 |
| スマホ表示の余白を調整 | 大幅改善 |
| sitemapに新規ページを追加 | 何をしたか分からない変更 |
add beginner link to top page
fix mobile spacing on guide cards
add safety examples section
update sitemap for new guide page
日本語で書く場合:
トップページに初心者向け導線を追加
安全ページにNG例を追加
ガイドカードのスマホ余白を調整ブランチとは
ブランチは、本体とは別に作業するための分岐です。mainを直接触らず、作業用ブランチで変更すると、本体への影響を確認しながら進めやすくなります。
ブランチは、本番ノートを汚さずに下書きノートで試すようなものです。機能追加、修正、検証ごとにブランチを分けると、作業内容が追いやすくなります。
| 分かりやすいブランチ名 | 分かりにくいブランチ名 |
|---|---|
| feature/add-beginner-guide | test |
| fix/internal-link-check | new |
| update/safety-examples | aaa |
| review/github-terms-page | fix |
注意 ブランチを分ければ何をしても安全という意味ではありません。変更内容を確認し、Pull Requestでレビューしてから取り込むことが大切です。
Pull Requestとは
Pull Requestは、変更を本体に取り込む前に確認してもらうための提案です。略してPRと呼ぶこともあります。
PRでは差分を見たり、コメントやレビューをしたりできます。問題があれば修正し、確認後にマージします。CodexにPRレビューを頼める場合もありますが、AIレビューだけで完了扱いにせず、人間が最終確認してください。
初心者向けに言うと、Pull Requestは「この変更を本体に入れてよいですか？」と確認してもらう提出箱のようなものです。
目的
変更したファイル
変更内容
確認したこと
未確認事項
リスク
戻す場合の注意このPull Requestをレビューしてください。
重大な不具合、セキュリティ上の問題、SEOタグの意図しない変更、外へ出せない情報の混入、不要ファイルの混入、戻しにくい変更がないか確認してください。
軽微な好みの指摘ではなく、実害がありそうな点を優先してください。4つの流れをまとめると
- リポジトリを用意するサイトやアプリのファイルを置く
- ブランチを作る本体とは別の場所で作業する
- ファイルを変更する必要な部分だけ直す
- コミットする変更内容を記録する
- Pull Requestを作る変更を提案として出す
- 差分を確認する何が変わったかを見る
- レビューする問題がないか確認する
- 問題なければマージする本体へ取り込む
この流れを理解すると、GitHubでいきなり本体を壊すリスクを減らしながら作業できます。
初心者がやりがちな失敗
| 悪い例 | 良い例 |
|---|---|
| mainを直接編集する | 作業ブランチを作る |
| コミットメッセージが「修正」だけ | 変更内容が分かる名前にする |
| ブランチ名が分かりにくい | 目的が分かるブランチ名にする |
| Pull Requestを作らず変更を入れる | PRで差分を見る |
| PR本文に何をしたか書かない | 目的と確認結果を書く |
| 大量の変更を1つにまとめる | 小さめに分ける |
| 外へ出せない情報をリポジトリに入れる | 重要な接続情報は置かない |
| AIレビューだけで確認を終える | 人間が最終確認する |
CodexやChatGPTと組み合わせる時の考え方
| ChatGPTでできること | Codexでできること |
|---|---|
| GitHub用語を日本語で説明してもらう | 変更ファイルを確認する |
| Issue文を作る | PR差分を確認する |
| PR本文を下書きする | 外へ出せない情報の混入を確認する |
| 変更内容を要約する | SEOタグ変更の有無を確認する |
| Codexへの作業指示を作る | 不要ファイル混入を確認する |
注意 GitHubやCodexの機能は変わる可能性があります。最新情報は提供元情報を確認し、コードやファイルの変更後は人間が確認してください。
GitHub基本用語チェックリスト
- リポジトリが何か説明できる
- コミットが変更の記録だと分かる
- ブランチが作業用の分岐だと分かる
- Pull Requestが変更確認の提案だと分かる
- mainを直接触りすぎない
- 変更内容が分かるコミット名にする
- PR本文に目的と確認結果を書く
- 外へ出せない情報をリポジトリに入れない
- AIレビューだけで終わらせない
- 人間が最終確認する
関連ページ
GitHubを実務でどう使うか
GitHubをコードの図書館から、変更履歴、差分確認、Codex作業対象、公開前チェックの記録場所へ広げて使うための具体例です。
このカテゴリの親ページへ戻る
同じカテゴリのページを続けて読む場合は、親ページの一覧から選ぶと迷いにくくなります。
近いテーマの読み分け
GitHubはコード履歴と差分確認の置き場です。秘密情報を避け、Codex作業場所として整えます。
GitHub基礎から実務へ
検索や個別ページから入った場合は、親カテゴリや近い実務ページへ進むと全体像をつかみやすくなります。