用語解説
第6章 変更をレビューにつなげる
この章では、手元で書いた変更を、チームが読めてレビューできる形に変えていく。GitとGitHubで使う基本的な用語を、基礎から応用へ順に並べる。読み方や略語の正式名称もあわせて押さえると、公式ドキュメントや実務でも迷わなくなる。
Git
- 読み：ギット（Git）／略語ではない固有名称
- 一言で言うと：手元で変更の履歴を記録・管理する仕組み。
- くわしく：Gitは、ファイルの変更をcommitという単位で履歴に残し、あとから誰が何のために何を変えたかを追えるようにするツールである。複数の作業を並行して進めるためのbranchや、変更を取り消す仕組みも持つ。一人の手元でも使えるが、チームで履歴を共有すると効果が大きい。なぜ必要かというと、保存し直すたびに上書きされるだけでは「いつ・なぜ変えたか」が消えてしまうからである。ターミナルやエディタから操作するのが基本である。
- 具体例：支援ステータス機能で空状態の案内文を追加するとき、その変更をGitでcommitすると「Add empty state copy」のような履歴として残せる。
- つまずきやすい点：Gitを「ファイルを保存するだけの道具」と思ってしまう。実際は変更の理由と単位を残すための道具である。
- 関連語：GitHub、commit、branch、repository（第6章）
- テキスト本文での登場箇所：第6章「GitとGitHubを分けて考える」
GitHub
- 読み：ギットハブ（GitHub）／固有のサービス名
- 一言で言うと：Gitの履歴をチームで共有し、Pull Requestやレビューを行うサービス。
- くわしく：GitHubは、Gitで作った履歴をインターネット上で共有する場所である。ブラウザやGitHub CLI（
gh）から、Pull Requestの作成、review commentのやり取り、mergeなどの共同作業を行う。Gitが手元の作業なのに対し、GitHubは共有とレビューの場という違いがある。なぜ必要かというと、手元の履歴だけではチームが変更を見たり議論したりできないからである。GitHub以外にもGitLabなど似たサービスがある。 - 具体例：支援ステータス機能の変更をbranchごとGitHubへpushし、Pull Requestを作ると、メンターチームがブラウザで差分を見てコメントできる。
- つまずきやすい点：GitとGitHubを同じものと思ってしまう。Gitは仕組み、GitHubはそれを共有・レビューする場所である。
- 関連語：Git、Pull Request、review comment、push、remote（第6章）
- テキスト本文での登場箇所：第6章「GitとGitHubを分けて考える」
repository
- 読み：リポジトリ（repository）／略してrepoとも書く
- 一言で言うと：Gitが履歴を管理している一つの作業場所。
- くわしく：repositoryは、あるプロジェクトの全ファイルとその変更履歴をまとめて持つ単位である。手元のディレクトリにある状態をlocal repository、GitHubなど共有先にある状態をremote repositoryと呼ぶ。作業を始める前に「どのrepositoryにいるか」を確認するのが現在地確認の第一歩である。なぜ必要かというと、別のrepositoryやbranchで作業してしまう事故を防ぐためである。
- 具体例：支援ステータス機能を直すときは、まず自分が支援ステータス用のrepositoryの中で作業しているかを確認する。
- つまずきやすい点：repositoryとフォルダを混同する。Gitが履歴を管理しているフォルダだけがrepositoryである。
- 関連語：Git、remote、branch、commit（第6章）
- テキスト本文での登場箇所：第6章「作業前にrepositoryの現在地を見る」
working tree
- 読み：ワーキングツリー（working tree）／作業ツリー
- 一言で言うと：いま編集しているファイル群の現在の状態。
- くわしく：working treeは、エディタで開いて編集している実際のファイルの状態である。ファイルを書き換えると、まずworking treeに変更が現れる。この段階ではまだcommitにもstaging areaにも入っていない。なぜ区別するかというと、編集しただけの状態と、履歴に残すと決めた状態を分けて考えるためである。
git statusでworking treeに変更があるかを確認できる。 - 具体例：支援ステータス機能のファイルに案内文を書き足した直後は、その変更はworking treeにある状態である。
- つまずきやすい点：編集すれば自動でcommitに入ると思ってしまう。working treeの変更は、stagingしてcommitするまで履歴に残らない。
- 関連語：staging area、commit、diff、status（第6章）
- テキスト本文での登場箇所：第6章「working tree、staging area、commit」
staging area
- 読み：ステージングエリア（staging area）／インデックスとも呼ぶ
- 一言で言うと：次のcommitに含める変更を選んで置く場所。
- くわしく：staging areaは、working treeの変更のうち「次のcommitに入れる」と決めたものを一時的に置く場所である。
git addで変更をstaging areaへ入れ、git commitでその内容を履歴に残す。working treeとcommitの間にこの段階があるおかげで、変更の一部だけを選んでcommitできる。なぜ必要かというと、関係ない変更を混ぜず、目的が一つにまとまったcommitを作るためである。 - 具体例：支援ステータス機能の本体ファイルだけをstaging areaに入れ、作業メモのファイルは入れないことで、案内文追加だけのcommitを作れる。
- つまずきやすい点：
git addで変更が完成・確定すると思ってしまう。addは「次のcommitに入れる候補として選ぶ」操作にすぎない。 - 関連語：staging（git add）、commit、staged diff、working tree（第6章）
- テキスト本文での登場箇所：第6章「working tree、staging area、commit」
staging（git add）
- 読み：ステージング（staging）／
git add（ギットアド） - 一言で言うと：変更を次のcommitに入れる候補としてstaging areaに置く操作。
- くわしく：
git add <file>は、指定したファイルの変更をstaging areaへ入れる操作である。git add .は変更全部をまとめて入れるが、意図しないファイルまで含めてしまうことがある。addした後に同じファイルをさらに編集すると、staging済みの差分と、まだstagingしていない差分が同時に存在しうる。なぜ慎重に使うかというと、何をcommitに入れたかを自分で把握するためである。初学者のうちはgit statusで変更を見てから、必要なファイルを明示するのが安全である。 - 具体例：支援ステータス機能なら
git add src/server.jsのように、変更したファイルを名前で指定してstagingする。 - つまずきやすい点：
git add .の後にgit diff --stagedを見ずにcommitする。何をstagingしたかは必ず確認する。 - 関連語：staging area、staged diff、status、commit（第6章）
- テキスト本文での登場箇所：第6章「working tree、staging area、commit」
commit
- 読み：コミット（commit）
- 一言で言うと：選んだ変更を履歴に残す一つの作業単位。
- くわしく：commitは、staging areaに入れた変更を履歴として確定させる単位である。
git commit -m "..."で作る。commitは単なる保存ボタンではなく、あとから読んだ人が「何のために何を変えたか」を追える区切りである。一つのcommitに一つの目的をまとめると、履歴が読みやすくなる。なぜ必要かというと、変更を意味のある単位に分けておくことで、レビューや問題発生時の切り分けがしやすくなるからである。 - 具体例：支援ステータス機能の空状態案内文だけを
Add empty state copy for progress listというcommitとして残す。 - つまずきやすい点：commit messageを書いたことで差分確認まで済んだ気になる。messageは説明の入口で、実際の中身は
git diff --stagedで確かめる。 - 関連語：commit message、staging area、diff、log（第6章）
- テキスト本文での登場箇所：第6章「working tree、staging area、commit」
commit message
- 読み：コミットメッセージ（commit message）
- 一言で言うと：そのcommitで何を変えたかを表す短い説明文。
- くわしく：commit messageは、commitに付ける説明である。未来の読者（自分やチーム）が履歴を追うための手がかりになる。
fixやupdateだけでは何を直したか分からないので、対象と変更内容が読める形にする。なぜ大事かというと、履歴を後から読むとき、messageが最初の入口になるからである。ただしmessageは証拠ではないので、本当にその変更だけが入っているかは差分で確認する。 - 具体例：支援ステータス機能なら
Add empty state copy for progress listのように、対象（進捗一覧）と変更（空状態の文言追加）が分かるように書く。 - つまずきやすい点：
fixだけのような短すぎるmessageにしてしまい、後から何を直したか分からなくなる。 - 関連語：commit、log、diff（第6章）
- テキスト本文での登場箇所：第6章「commit前に差分を読む」
status（git status）
- 読み：ステータス（status）／
git status（ギットステータス） - 一言で言うと：working treeとstaging areaの今の状態を確認するコマンド。
- くわしく：
git statusは、変更があるか、その変更がstaging済みか、Gitに追跡されていない（untrackedな）ファイルかを表示する。作業前の現在地確認でも、commit直前でも使う基本コマンドである。なぜ頻繁に使うかというと、Gitの事故の多くは現在地を見ずに進めたことから起きるからである。 - 具体例：支援ステータス機能の作業を始める前に
git statusを見て、commitしていない前の作業が残っていないかを確認する。 - つまずきやすい点：statusを見ずにbranchやcommitを作ると、前の作業の残りが混ざる。作業の節目ごとに見る習慣をつける。
- 関連語：working tree、staging area、diff、branch（第6章）
- テキスト本文での登場箇所：第6章「作業前にrepositoryの現在地を見る」
diff
- 読み：ディフ（diff／difference の略）
- 一言で言うと：変更前と変更後の違いを行単位で見たもの。
- くわしく：diffは、追加された行・削除された行・変わったファイルを表示する。
git diffはまだstagingしていない変更を見る。差分を読む目的は間違い探しだけでなく、自分がチームに渡す変更を自分の言葉で説明できるか確かめることである。なぜ必要かというと、AIが書いた変更でも、読まずにレビューへ渡せないからである。 - 具体例：支援ステータス機能で案内文を足したら、commit前に
git diffで追加した行を読み、意図どおりかを確認する。 - つまずきやすい点：
git diffはstaging前の差分しか見せない。staging後の差分はgit diff --stagedで別に見る必要がある。 - 関連語：staged diff、status、commit（第6章）
- テキスト本文での登場箇所：第6章「commit前に差分を読む」
staged diff
- 読み：ステージドディフ（staged diff）／
git diff --staged - 一言で言うと：次のcommitに入る予定の差分。
- くわしく：
git diff --stagedは、staging areaに入れた変更、つまり次のcommitに含めると決めた差分だけを見せる。working tree全体の差分ではなく、commitに含める分だけを確認できる。なぜ必要かというと、git addした後に何をcommitしようとしているかを正確に把握し、関係ない変更や秘密情報の混入を防ぐためである。commit直前には必ず見る。 - 具体例：支援ステータス機能でファイルをaddした後、
git diff --stagedを見て、案内文の追加だけがcommitに入ることを確認する。 - つまずきやすい点：
git add .の後にstaged diffを見ずにcommitしてしまう。stagingした内容は必ずこのコマンドで確かめる。 - 関連語：diff、staging area、staging（git add）、commit（第6章）
- テキスト本文での登場箇所：第6章「commit前に差分を読む」
branch
- 読み：ブランチ（branch）
- 一言で言うと：本流を直接変えずに作業を進めるための分かれ道。
- くわしく：branchは、main branchなどの安定した状態を保ったまま、新しい機能や修正を別の流れで進める仕組みである。多くのチームは安定版をmainに置き、作業は作業用branchで行う。branch名は目的が分かる名前にし、一つのbranchに一つの目的を持たせるのが大切である。なぜ必要かというと、目的を分けたbranchはレビューしやすく、問題が起きたときに戻しやすいからである。
- 具体例：支援ステータス機能の空状態追加なら
feature/progress-empty-stateのようなbranchを作り、その作業だけを進める。 - つまずきやすい点：一つのbranchに複数の目的（空状態追加とフィルタ仕様変更など）を混ぜると、レビューする人が判断しにくくなる。
- 関連語：main、commit、merge、Pull Request（第6章）
- テキスト本文での登場箇所：第6章「branchは、作業の目的を分ける」
remote
- 読み：リモート（remote）
- 一言で言うと：履歴の共有先となる、手元の外にあるrepository。
- くわしく：remoteは、GitHubなど手元の外にある共有先のrepositoryを指す名前である。よく使う既定の名前が
originである。git remote -vで、どのremoteを向いているかを確認できる。なぜ必要かというと、想定外のremoteへpushする事故を防ぎ、正しい共有先に変更を送るためである。 - 具体例：支援ステータス機能の作業前に
git remote -vを見て、originが想定したGitHub repositoryを向いているか確認する。 - つまずきやすい点：remoteの確認を飛ばすと、別のrepositoryへpushしてしまうことがある。作業前に向き先を見ておく。
- 関連語：push、repository、GitHub、branch（第6章）
- テキスト本文での登場箇所：第6章「作業前にrepositoryの現在地を見る」
push
- 読み：プッシュ（push）
- 一言で言うと：手元のcommitをremoteへ送って共有する操作。
- くわしく：pushは、手元のbranchとcommitをremote（GitHubなど）へアップロードし、チームが見られるようにする操作である。pushして初めてPull Requestを作れる。なぜ必要かというと、手元の履歴だけではチームが変更を見られないからである。なお
git push --forceはremoteの履歴を書き換えることがあり、チームのbranchでは独断で使ってはいけない。 - 具体例：支援ステータス機能のcommitを作ったら、作業branchをpushしてGitHub上でPull Requestを作る。
- つまずきやすい点：
git push --forceを意味が分からないまま実行すると、共有先の履歴を壊すことがある。研修中は使う前に相談する。 - 関連語：remote、commit、Pull Request
- テキスト本文での登場箇所：第6章「GitとGitHubを分けて考える」
Pull Request
- 読み：プルリクエスト（Pull Request）／略してPR
- 一言で言うと：branchの変更をチームに見せてレビューしてもらう単位。
- くわしく：Pull Request（PR）は、作業branchの変更を共有し、取り込んでよいか判断してもらうための提案である。完成報告の場ではなく、差分・本文・会話の三つで成り立つ。良いPR本文には、背景、変更内容、今回やらないこと、確認方法、影響範囲とリスク、レビューしてほしい点、AIを使った場合の検証が入る。なぜ必要かというと、差分だけではなぜ・何を・どう確認したかが伝わらず、レビュアーが判断できないからである。
- 具体例：支援ステータス機能の空状態追加PRでは、「担当受講者0件のとき空白に見える」背景と、案内文を表示した変更内容、確認方法を本文に書く。
- つまずきやすい点：「進捗一覧を直しました」だけの本文にしてしまう。なぜ・何を・どう確認したか・どこを見てほしいかを書く。
- 関連語：review comment、merge、branch、diff（第6章）
- テキスト本文での登場箇所：第6章「Pull Requestは、完成報告ではなく変更提案である」
review comment
- 読み：レビューコメント（review comment）
- 一言で言うと：Pull Requestに対してレビュアーが書く指摘や質問。
- くわしく：review commentは、レビュアーが差分や本文を見て残すコメントである。受け取ったら感情的に受け取らず、修正する・質問する・別PRに分ける・代替案を出す、のどれで返すかを判断する。返信には、指摘の理解、判断、今回の対応範囲、確認結果を書く。なぜ必要かというと、レビューは間違い探しではなく、変更を安全に取り込むための共同作業だからである。
- 具体例：支援ステータス機能で「0件とフィルタ結果0件で文言を分けたい」というreview commentが来たら、両者の違いを理解した上で対応範囲を返信する。
- つまずきやすい点：返信を「修正しました」だけで終え、判断や確認結果を残さない。何を変えどう確認したかも短く書く。
- 関連語：Pull Request、merge、commit（第6章）
- テキスト本文での登場箇所：第6章「レビューコメントには、次の行動で返す」
merge
- 読み：マージ（merge）
- 一言で言うと：あるbranchの変更を別のbranchに取り込んで一つにする操作。
- くわしく：mergeは、作業branchの変更をmainなどへ統合する操作である。Pull Requestがレビューを通ると、最終的にmergeされて変更が本流に入る。複数のbranchが同じ箇所を別々に変えていると、mergeのときにconflictが起きることがある。なぜ必要かというと、分けて進めた作業を最終的に一つの状態へまとめるためである。
- 具体例：支援ステータス機能の空状態追加PRがレビューを通ったら、mainにmergeされて全員の環境に反映される。
- つまずきやすい点：mergeすれば必ず自動で一つになると思ってしまう。同じ箇所が衝突するとconflictになり、人の判断が要る。
- 関連語：branch、conflict、Pull Request、main（第6章）
- テキスト本文での登場箇所：第6章「GitとGitHubを分けて考える」
conflict
- 読み：コンフリクト（conflict）／競合
- 一言で言うと：Gitが自動では最終状態を決められない変更が衝突した状態。
- くわしく：conflictは、同じ箇所を二つのbranchが別々に変更したときなどに起きる。失敗ではなく、人間の判断が必要だというサインである。解消では、どのファイルが衝突しているかを
git statusで見て、それぞれの変更意図を読み、どちらを残すか・両方を別条件として残すかを決める。なぜ必要かというと、機械的にどちらかを残すと、別の状態を表す変更を取りこぼすことがあるからである。 - 具体例：支援ステータス機能で「担当受講者0件」の文言と「フィルタ結果0件」の文言が衝突したら、利用者の次の行動が違うため、二つを別状態として扱うか検討する。
- つまずきやすい点：conflict markerを消すことだけに集中し、両方の変更意図を読まない。文字列整理ではなく意図の読み直しである。
- 関連語：conflict marker、merge、branch、log（第6章）
- テキスト本文での登場箇所：第6章「conflictは、人間の判断が必要というサインである」
conflict marker
- 読み：コンフリクトマーカー（conflict marker）
- 一言で言うと：conflict箇所を示すためにGitが入れる目印の記号。
- くわしく：conflict markerは、衝突した部分を
<<<<<<<、=======、>>>>>>>の記号で囲んで示す。<<<<<<< HEADから=======までが一方の変更、=======から>>>>>>> ...までがもう一方の変更である。通常のmergeではHEADが現在checkoutしているbranch側を指す。解消では、両方の意図を読んだ上でmarkerを消し、最終的に残すコードや文言だけにする。なぜ必要かというと、どこがどちらの変更か分からないと判断できないからである。 - 具体例：支援ステータス機能のconflictで、HEAD側に「担当受講者が割り当てられると…」、相手側に「条件に一致する受講者はいません…」と並んでいたら、それぞれが何の状態かを読む。
- つまずきやすい点：rebaseなど操作の種類によってHEADと相手側の見え方が紛らわしくなる。markerだけで判断せず、何の操作中かも確認する。
- 関連語：conflict、merge、checkout（第6章）
- テキスト本文での登場箇所：第6章「conflictは、人間の判断が必要というサインである」
log（git log）
- 読み：ログ（log）／
git log（ギットログ） - 一言で言うと：これまでのcommit履歴を一覧で見るコマンド。
- くわしく：
git logは、過去のcommitを新しい順に表示する。git log --oneline -5のようにすると、直近5件を1行ずつ簡潔に見られる。作業前の現在地確認や、conflict解消時の判断材料として使う。なぜ必要かというと、どの変更がどの目的でどの確認を経て入ったかを知ることが、現在の判断につながるからである。履歴を見るのは犯人探しではない。 - 具体例：支援ステータス機能のconflictを解消する前に
git log --oneline -5を見て、フィルタ結果0件の文言が別PRで追加されていたかを確認する。 - つまずきやすい点：履歴を「誰のせいか」を探すために見てしまう。目的は、変更の理由と確認の経緯を知ることである。
- 関連語：commit、show、conflict（第6章）
- テキスト本文での登場箇所：第6章「作業前にrepositoryの現在地を見る」
show（git show）
- 読み：ショー（show）／
git show（ギットショー） - 一言で言うと：特定のcommitの差分や内容を詳しく見るコマンド。
- くわしく：
git show <commit-sha>は、指定したcommitが何を変えたかを差分つきで表示する。git logで見つけた気になるcommitの中身を確認するときに使う。なぜ必要かというと、履歴の一覧だけでは「そのcommitで具体的に何が変わったか」までは分からないからである。conflict解消や経緯の調査で役に立つ。 - 具体例：支援ステータス機能で過去に文言を変えたcommitを
git showで開き、どんな表現が入っていたかを確かめる。 - つまずきやすい点：
git logと混同する。logは一覧、showは一つのcommitの中身を見る。 - 関連語：log、commit、diff（第6章）
- テキスト本文での登場箇所：第6章「conflictは、人間の判断が必要というサインである」
checkout
- 読み：チェックアウト（checkout）
- 一言で言うと：あるbranchやcommitの状態を作業ツリーに取り出すこと。
- くわしく：checkoutは、指定したbranchやcommitの状態を手元のworking treeへ反映する操作である。conflict markerの説明では「現在checkoutしているbranch側」がHEADとして示される、という形で出てくる。なぜ覚えておくかというと、自分が今どのbranchをcheckoutしているかが、conflict markerの読み方やmergeの結果に関わるからである。
- 具体例：支援ステータス機能のmergeでconflictが出たとき、HEADは自分がcheckoutしているbranchの変更を指す、と読む。
- つまずきやすい点：HEADを常に「main」と思い込む。HEADはそのとき自分がcheckoutしているbranchを指す。
- 関連語：branch、conflict marker、merge（第6章）
- テキスト本文での登場箇所：第6章「conflictは、人間の判断が必要というサインである」
main（main branch）
- 読み：メイン（main）／main branch
- 一言で言うと：安定した状態を置く、本流となるbranch。
- くわしく：main branchは、多くのチームで「安定した状態」を置く基準のbranchである。新しい機能や修正は作業用branchで進め、レビューを通してからmainにmergeする。なぜ必要かというと、常に動く状態を一つ決めておくことで、そこを基準に作業を分けて進められるからである。
- 具体例：支援ステータス機能の作業前に
git branch --show-currentで、mainにいるか作業branchにいるかを確認する。 - つまずきやすい点：mainで直接作業してしまう。新しい変更は作業用branchで進めるのが基本である。
- 関連語：branch、merge、Pull Request（第6章）
- テキスト本文での登場箇所：第6章「branchは、作業の目的を分ける」
.gitignore
- 読み：ギットイグノア（.gitignore）
- 一言で言うと：Gitに追跡させないファイルを指定する設定ファイル。
- くわしく：.gitignoreは、ログ、生成物、
.envのような秘密情報を含むファイルなど、履歴に残したくないファイルをGitの追跡対象から外すためのファイルである。本文では直接の節はないが、commitに混ぜてはいけないファイル（メモ、ログ、.env、依存関係のlock fileなど）の話と密接に関わる。なぜ必要かというと、秘密情報や不要な生成物がcommitに混入するのを仕組みで防ぐためである。 - 具体例：支援ステータス機能の作業で作った
.envや一時ログを.gitignoreに書いておくと、git add .でも誤って混ざらない。 - つまずきやすい点：すでにcommit済みのファイルは、後から.gitignoreに書いても追跡が止まらない。最初から対象外にしておく。
- 関連語：staging（git add）、status、commit（第6章）
- テキスト本文での登場箇所：第6章「commit前に差分を読む」
gh（GitHub CLI）
- 読み：ジーエイチ（GitHub CLI）／コマンド名は
gh - 一言で言うと：GitHubの操作をターミナルから行う公式コマンドラインツール。
- くわしく：
ghは、Pull Requestの作成や確認などGitHub上の操作を、ブラウザを開かずターミナルから行うためのツールである。GitHubはブラウザで操作するのが基本だが、ghを使うとコマンドで同じことができる。なぜ便利かというと、作業の流れをターミナルで完結させやすくなるからである。 - 具体例：支援ステータス機能の作業で、ブラウザを開かず
ghを使ってPull Requestを作る、という選択肢がある。 - つまずきやすい点：
ghはGit（git）コマンドとは別物である。ghはGitHub側の操作、gitは手元のGit操作を担う。 - 関連語：GitHub、Pull Request、push（第6章）
- テキスト本文での登場箇所：第6章「GitとGitHubを分けて考える」
HEAD
- 読み：ヘッド（HEAD）
- 一言で言うと：いま自分がいる位置。checkout中のbranchやcommitの先端を指す印。
- くわしく：Gitは作業の基準点をHEADという印で覚えている。多くの場合HEADは現在のbranchの最新commitを指す。branchを切り替えるとHEADも一緒に動く。conflictのとき、conflict markerの上側（
<<<<<<< HEAD）が、いまのHEAD側の内容である。 - 具体例：feature branchで作業中にmainの変更を取り込んでconflictが起きると、
<<<<<<< HEADから=======までが自分のbranch側、=======から>>>>>>>までが取り込む相手側になる。 - つまずきやすい点：HEADを常にmainだと思い込む。HEADは「いまcheckoutしている場所」であって、特定のbranch名ではない。
- 関連語：branch（第6章）、checkout（第6章）、conflict marker（第6章）
- テキスト本文での登場箇所：第6章「conflictは、人間の判断が必要というサインである」
git switch
- 読み：ギットスイッチ（git switch）
- 一言で言うと：branchを切り替える、または新しく作って切り替えるコマンド。
- くわしく：
git switch ブランチ名で既存のbranchへ移り、git switch -c 新しいブランチ名で新しいbranchを作って同時に移る。以前はgit checkoutが切り替えと復元を兼ねて分かりにくかったため、切り替え専用のgit switchが用意された。作業を始める前に、目的に合った名前のbranchへ移ってから変更する。 - 具体例：空状態の表示を直すなら、
git switch -c feature/progress-empty-stateで作業用branchを作ってから編集を始める。 - つまずきやすい点：
-cを付け忘れると、存在しないbranchへ切り替えようとして失敗する。新規作成時は-cが要る。 - 関連語：branch（第6章）、checkout（第6章）、HEAD（第6章）
- テキスト本文での登場箇所：第6章「branchは、作業の目的を分ける」