📚 Guilders HQ Docs
トップ / gen / Git / GitHub 基本勉強会

Git / GitHub 基本勉強会

チームメンバー向けの Git / GitHub 基礎ハンズオン勉強会資料。想定所要時間 90〜120 分。

draft 作業者: gen 著者: gen 最終レビュー: 2026-04-22 所要 90 分

本資料の位置づけ: チームで共通の語彙とワークフローを揃えるための基礎勉強会。 想定参加者: Git / GitHub を使ったことはあるが、自信を持って説明できない人。 信頼度: 特記なき事項は FACT（公式ドキュメント準拠）。

0. この勉強会のゴール FACT

終わったときに、以下を「自分の言葉で」説明・実行できる状態を目指します。

  1. ワーキングツリー / インデックス / ローカルリポジトリ / リモートリポジトリの違いを図解できる
  2. git add → git commit → git push の流れを単独で実行できる
  3. ブランチを切り、Pull Request を作り、レビューを受けてマージするまでの一連を実行できる
  4. コンフリクトが起きたとき、パニックにならずに解消できる
  5. 「やらかした」と思ったときに、壊れたのがローカルか共有かを判断できる

出典: Git 公式ドキュメント Getting Started（https://git-scm.com/doc）、GitHub Docs "Get started"（https://docs.github.com/ja/get-started）。

1. そもそも Git とは何か FACT

Git は 分散型バージョン管理システム (Distributed Version Control System, DVCS)。

出典: Pro Git 1.1 "About Version Control"（https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%AE%A1%E7%90%86%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6）。

Git と GitHub の違い FACT

項目 Git GitHub
正体 バージョン管理ツール（ソフトウェア） Git リポジトリをホスティングするサービス
提供元 オープンソース（Software Freedom Conservancy 傘下） Microsoft 子会社
なくても困るか 困る（ローカル作業の根幹） 困るが代替あり（GitLab, Bitbucket 等）

出典: https://git-scm.com/about, https://docs.github.com/ja/get-started/start-your-journey/about-github-and-git。

2. Git の 4 つの領域 FACT

Gitの4つの領域を横断するフロー図

これを体に染み込ませると、あとのコマンドが全部「どの領域からどの領域へ動かすか」で理解できます。

[ワーキングツリー]  ──git add──▶  [インデックス/ステージ]  ──git commit──▶  [ローカルリポジトリ]  ──git push──▶  [リモートリポジトリ]
       ▲                                   │                                     │                                   │
       │                                   │                                     │                                   │
       └─────────── git checkout / git restore ──────────── git reset ───────────┘                                   │
                                                                                                                     │
                                                  git fetch / git pull ◀────────────────────────────────────────────┘

出典: Pro Git 2.2 "Recording Changes to the Repository"（https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E5%A4%89%E6%9B%B4%E5%86%85%E5%AE%B9%E3%81%AE%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%81%B8%E3%81%AE%E8%A8%98%E9%8C%B2）。

3. 最初の 10 コマンドだけ覚える FACT

この 10 個で日常業務の 9 割はカバーできます（※ 9 割は経験則 INFERENCE）。

# コマンド 何をするか
1 git clone <url> リモートリポジトリをローカルに複製
2 git status 今の状態を確認（迷ったらまずこれ）
3 git diff 未ステージの変更を見る（--staged でステージ済みを見る）
4 git add <path> 変更をステージに上げる
5 git commit -m "..." ステージの内容をコミットする
6 git log --oneline --graph --decorate 履歴を見る
7 git switch -c <branch> 新しいブランチを作って切り替える
8 git fetch リモートの最新を取得（マージはしない）
9 git pull --rebase fetch + rebase（推奨。理由は §6）
10 git push ローカルコミットをリモートに送る

出典: git help <command> および https://git-scm.com/docs。

補足: git checkout の分割 FACT

Git 2.23（2019-08-16 リリース）で git checkout の役割が分割されました。新規コードでは以下を推奨します。

git checkout は今も動きますが、意味が過多で事故の元です。出典: Git 2.23 リリースノート（https://github.com/git/git/blob/master/Documentation/RelNotes/2.23.0.txt）。

4. ハンズオン: 最初のコミットから push まで（20 分）

4.1 事前準備 FACT

# 名前とメールを設定（コミットに記録される。公開されるので注意）
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# デフォルトブランチ名を main に（2020 年以降のデファクト）
git config --global init.defaultBranch main

# pull 時に自動で rebase
git config --global pull.rebase true

出典: https://docs.github.com/ja/get-started/git-basics/set-your-username-in-git, https://github.blog/open-source/git/highlights-from-git-2-28/（init.defaultBranch の導入）。

4.2 手順

# 1. リポジトリを clone
git clone https://github.com/<org>/<repo>.git
cd <repo>

# 2. ブランチを切る
git switch -c feature/my-first-change

# 3. 適当なファイルを編集（例: README に 1 行追記）
echo "Hello from $(whoami)" >> README.md

# 4. 状態を確認
git status
git diff

# 5. ステージ → コミット
git add README.md
git commit -m "docs: add hello line from $(whoami)"

# 6. push
git push -u origin feature/my-first-change

-u は「次回以降 git push だけで済むように上流ブランチを紐付ける」おまじないです。出典: git push --help。

5. GitHub の Pull Request ワークフロー FACT

GitHub は Git リポジトリを共有する「場所」ですが、最大の価値は Pull Request（PR）を通じたレビュー文化 にあります。

5.1 PR の基本ライフサイクル

Pull Request の 7 ステップ・ライフサイクル

  1. ブランチを切ってコミット・push する（§4）
  2. GitHub 上で「Compare & pull request」ボタンから PR を作成
  3. タイトルと説明を書く（何を・なぜ・どうテストしたか）
  4. レビュアーをアサインし、レビューを受ける
  5. 指摘に応じて追加コミット → push（PR は自動更新される）
  6. Approve を得て、マージする
  7. ブランチを削除する

出典: https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests。

5.2 PR 説明テンプレ（推奨） INFERENCE

この構造は GitHub Docs "About pull requests" および多くの OSS プロジェクトで共通して推奨されている形式を踏襲したもの。INFERENCE: 業界で広く採用されているという観察に基づく。

## Summary
- 何を変えたか（1〜3 行）

## Why
- なぜ必要か（リンクする issue, 背景）

## How
- どう実装したか（レビュアーが diff を読む順序の案内）

## Test plan
- [ ] 何をテストしたか
- [ ] どう確認すれば再現できるか

5.3 マージ戦略 3 種 FACT

Merge commit / Squash merge / Rebase merge の履歴比較

方式 履歴の見た目 向いている場面
Merge commit マージコミットが残る。分岐が見える 長寿命のフィーチャーブランチ
Squash merge 1 コミットに圧縮される 小さな PR、履歴を一本道にしたい
Rebase merge マージコミットなしで直列につながる コミット単位でレビュー価値がある場合

チームでどれを使うかは先に決めて README に書いておくと事故が減ります（OPINION 注: 経験的な推奨。採用はチーム判断）。出典: https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges。

6. なぜ pull --rebase を推奨するのか INFERENCE

デフォルトの git pull（= fetch + merge）は、リモートの変更をローカルに取り込むたびにマージコミットを作ります。個人開発ならよいですが、複数人で同じブランチを触ると履歴が「Y 字」「X 字」に入り組み、git log --graph が読めなくなります。

出典: Pro Git 3.6 "Rebasing"（https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%99%E3%83%BC%E3%82%B9）。

7. コンフリクト解消の手順 FACT

コンフリクト解消 6 ステップと --abort での退避ルート

  1. git pull --rebase や git merge 実行時に「CONFLICT」が表示されたら慌てない
  2. git status で衝突しているファイルを確認
  3. エディタで該当ファイルを開くと、以下のマーカーが挿入されている

``` <<<<<<< HEAD 自分の変更 ======= 相手の変更

origin/main ```

  1. マーカーを全部消し、最終的に残すべき内容を手で書く
  2. git add <ファイル> でマーカー除去を宣言
  3. git rebase --continue（rebase 中）または git commit（merge 中）

迷ったら git rebase --abort / git merge --abort で元に戻せます。 これを知っているだけで恐怖心が消えます。出典: git rebase --help, git merge --help。

8. 「やらかした」ときの復旧 FACT

push 前／後で分岐するやらかし復旧マップ

8.1 ローカルだけの失敗（共有前）

やらかし 復旧
まだコミットしてない変更を捨てたい git restore <path>
直前のコミットを修正したい git commit --amend（※ push 済みは禁止）
直前のコミットを取り消したい git reset --soft HEAD^（変更はワーキングツリーに戻る）
完全に最新コミットを捨てたい git reset --hard HEAD^（復旧不可、慎重に）

8.2 共有済みの失敗（push 後）

原則: 履歴を書き換えない。「打ち消しコミット」で対応する。

git push --force（強制プッシュ）は、他人の作業を消し飛ばす可能性があるため 共有ブランチでは原則禁止。どうしてもやるときは --force-with-lease を使い、チームに周知します。出典: git push --help。

8.3 最終兵器: git reflog FACT

「reset --hard で消した！」と思っても、直近のローカル操作は .git/logs/ に 30 日（デフォルト）残っています。

git reflog          # 直近の HEAD 移動履歴
git reset --hard <reflog の ID>

出典: git reflog --help、Pro Git 7.13 "Reset Demystified" 付録。

9. GitHub CLI (gh) で作業を加速する FACT

ブラウザを開かずに PR の作成・レビュー・マージができます。本リポジトリの前提ツールにも gh が含まれています（CLAUDE.md 参照）。

# PR を作る（タイトルと本文を対話形式で聞かれる）
gh pr create

# PR の一覧
gh pr list

# PR をチェックアウト（レビュー用に手元で動かしたいとき）
gh pr checkout <PR番号>

# PR をマージ（Squash）
gh pr merge --squash

出典: https://cli.github.com/manual/。

10. チーム運用で決めておきたい 5 項目 OPINION

以下はチーム判断事項であり、正解はありません。先に決めておかないと後で揉める項目の列挙です。採用判断は各チームで。

  1. ブランチ命名規則（例: feature/<issue番号>-<短い英語>, fix/..., docs/...）
  2. コミットメッセージ規約（Conventional Commits を採用するか否か）
  3. マージ方式（Squash / Rebase / Merge commit）
  4. レビュー必須人数（1 人 / 2 人 / CODEOWNERS に従う）
  5. 直接 push 禁止のブランチ（main は branch protection で守る）

参考: https://www.conventionalcommits.org/ja/v1.0.0/, https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches。

11. よくある質問 FACT / INFERENCE

Q. git add . と git add -A は何が違う？ FACT A. Git 2.0 以降、どちらも「サブディレクトリ含めて全変更をステージ」でほぼ同義。細かく言うと、git add . はカレント配下、git add -A はリポジトリ全体。出典: https://git-scm.com/docs/git-add。

Q. .gitignore に書いたのに無視されない FACT A. すでに追跡（track）されているファイルは .gitignore の影響を受けない。git rm --cached <file> で追跡解除してからコミットする。出典: https://git-scm.com/docs/gitignore。

Q. 間違って巨大ファイル（動画・ビルド成果物）をコミットしてしまった INFERENCE A. push 前なら git reset で戻す。push 後は git filter-repo（推奨）または BFG Repo-Cleaner で履歴から除去する。ただし 共有リポジトリで履歴書き換えはチーム全員に通知必須。INFERENCE: 公式ドキュメントが filter-branch より filter-repo を推奨している事実に基づく（https://git-scm.com/docs/git-filter-branch#_warning）。

Q. 秘密情報（API キー等）をコミットしてしまった FACT A. そのキーは「漏れた」と見なして即座にローテーション（無効化→再発行）する。 履歴から消しても、誰かが見た可能性は消えない。出典: https://docs.github.com/ja/code-security/secret-scanning/introduction/about-secret-scanning。

12. 宿題（次回までに） OPINION

宿題は推奨。強制ではありません。

  1. 自分の手元で空リポジトリを 1 つ作り、README だけで 5 コミット積んでみる
  2. わざとコンフリクトを起こして、解消してみる（ブランチを 2 つ作り、同じ行を違う内容で編集）
  3. git reflog を眺めて、自分の直近 20 操作を言語化する

付録 A. チートシート

# 状態確認
git status
git log --oneline --graph --decorate --all -20
git diff                      # 未ステージ
git diff --staged             # ステージ済み

# 変更を記録
git switch -c <branch>
git add <path>
git commit -m "type: message"
git push -u origin <branch>

# 取り込み
git fetch
git pull --rebase

# 取り消し
git restore <path>            # ワーキングツリーの変更を捨てる
git restore --staged <path>   # ステージから降ろす
git commit --amend            # 直前コミット修正（未 push のみ）
git revert <hash>             # 共有済みコミットの打ち消し

# 緊急脱出
git rebase --abort
git merge --abort
git reflog                    # 30 日以内なら救える

付録 B. 参考資料

付録 C. 本資料の信頼度まとめ

改訂履歴:

ソース: workspace/gen/2026-04-22-git-github-study-session.md

編集は Markdown を修正し、/publish-docs スキルで再ビルド・デプロイしてください。