この用語集の使い方
AIにGit操作を頼むときに使われる言葉を、作業場面ごとに整理した用語集です。すべてのコマンドを暗記する必要はありません。AIが使った言葉の意味を確かめ、次に何をしてよいか、何は止めてほしいかを伝えるために使ってください。
GitとGitHubの違いや、そもそも何のために使うのかから確認したい方は、「GitとGitHubとは何か、なぜ使うのか」を先に読んでください。
コマンド例のある用語では、説明のすぐ下に例を折りたたんでいます。初読では開かなくても、説明の流れは追えます。
まず、言葉を五つの場面に分ける
Gitの用語は、使う場面で分けると整理しやすくなります。
- 始める・状態を見る：repository、init、clone、status、diff
- 変更を記録する：working tree、stage、commit、HEAD
- 作業を分けて合流する：branch、switch、merge、conflict
- GitHubとやり取りする：local、remote、origin、fetch、pull、push、pull request
- 作業を退避する・変更を戻す：stash、restore、revert、reset
分からなくなったときは、「いまの変更はどの段階にあるか」を確認します。まだファイルを編集中なのか、次のコミットに選んだのか、手元の履歴へ記録したのか、GitHubへ送ったのか。この段階が分かれば、必要な操作も絞れます。
始める・状態を見る言葉
repository（リポジトリ）
プロジェクトのファイルとGitの履歴をまとめた単位です。略して「repo」と書かれることもあります。
会話では「GitHubのリポジトリ」がGitHub上の共有先を指し、「ローカルリポジトリ」が手元の履歴を指すことがあります。どちらも同じプロジェクトの履歴を扱いますが、置かれている場所が違います。
init
普通のフォルダを、Gitで管理し始める操作です。新しいプロジェクトを手元で作ったときに使います。initしただけではGitHubにリポジトリは作られず、ファイルも送られません。
initのコマンド例を見る
git init
git status
現在のフォルダをGitで管理し始め、続けて状態を確認する例です。実行するフォルダを間違えないよう、AIには対象のパスも確認させてください。
clone
GitHubなどにあるリモートリポジトリを、履歴ごと手元へ複製します。すでに共有されているプロジェクトへ参加するときの入口です。
cloneすると、通常は共有元がoriginという名前のリモートとして登録されます。
cloneのコマンド例を見る
git clone https://github.com/ユーザー名/リポジトリ名.git
ユーザー名とリポジトリ名は、実際のGitHub URLに合わせて置き換えます。非公開リポジトリでは、そのリポジトリを読む権限と認証が必要です。
status
現在のブランチ、変更したファイル、ステージしたファイル、Gitがまだ追跡していないファイルを表示します。Gitの状態が分からなくなったとき、最初に使いたい確認操作です。
AIには「作業前後のstatusを示して」と頼めます。既存の未コミット変更を誤って巻き込んでいないか確かめる手がかりになります。
statusのコマンド例を見る
git status --short --branch
現在のブランチとファイルの状態を、短い形式で表示します。
diff
ファイルの変更前後を比べます。statusが「どのファイルが変わったか」を示すのに対し、diffは「その中身がどう変わったか」を示します。
コミット前にAIに「diffを要約して」と頼むと、依頼した変更だけが含まれているか確認できます。
diffのコマンド例を見る
git diff
git diff --staged
一行目はまだステージしていない変更、二行目は次のコミットに入る変更を表示します。
変更を記録する言葉
working tree（ワーキングツリー）
現在、実際に編集しているプロジェクトのファイルがある場所です。エディタで保存した変更は、まずここにあります。
Gitでは、手元でファイルを編集している場所を「作業ツリー」または「作業ディレクトリ」と呼びます。どちらも同じものを指します。
stage / staging area（ステージ／ステージングエリア）
次のコミットに含める変更を選ぶ操作がstageです。選んだ変更が置かれる領域をstaging areaと呼びます。git addというコマンドを使いますが、GitHubへファイルを追加する操作ではありません。
AIには「今回の目的に関係するファイルだけをステージして」と頼めます。git add .のように全変更をまとめて選ぶ前に、対象を確認してもらうと安全です。
stageのコマンド例を見る
git add 変更したファイルのパス
git diff --staged
変更したファイルのパスには、実際に対象とするファイルのパスを入れます。続けて、次のコミットに入る差分を確認する例です。
commit
ステージした変更を、説明文と一緒にローカルの履歴へ記録します。コミットは、あとから変更の目的をたどれる作業単位です。
ファイルの保存、コミット、pushは別です。AIが「コミットしました」と言っても、その変更がGitHubへ送られたとは限りません。
commitのコマンド例を見る
git commit -m "ログインフォームを追加"
メッセージは、実際の変更内容に合わせます。AIには「一つの目的につき一つのコミットにして」と頼めます。
HEAD
現在チェックアウトしている履歴上の位置を指す名前です。多くの場合、いま作業しているブランチの最新コミットを指します。
HEAD~1は、現在位置から一つ前のコミットを表します。AIがHEADを使って履歴の位置を指定したときは、実行前にHEADがどこを指しているか確認してください。
HEADの位置を確認するコマンド例を見る
git branch --show-current
git log --oneline -5
現在のブランチ名と、直近のコミットを確認します。
作業を分けて合流する言葉
branch
コミットの流れの先端を指す名前です。機能追加、修正、実験を別のブランチで進めると、完成前の変更を基準ブランチから分けておけます。
ブランチはプロジェクトのコピーそのものではありません。最初は同じコミットを指し、その後に加えたコミットによって履歴の流れが分かれます。
branchのコマンド例を見る
git branch
git branch --show-current
手元にあるブランチの一覧と、現在のブランチ名を確認します。
switch
作業するブランチを切り替えます。切り替えると、ワーキングツリーのファイルも、そのブランチが指す状態に合わせて変わります。
未コミットの変更があると、安全に切り替えられず停止することがあります。AIには、切り替える前にstatusを確認させてください。
switchのコマンド例を見る
git switch 基準ブランチ名
git switch -c 作業ブランチ名
一行目の基準ブランチ名には、mainやdevelopなど実際の基準ブランチ名を入れます。二行目の作業ブランチ名には実際の作業用ブランチ名を入れ、-cで新しいブランチを作ると同時に切り替えます。
merge
別のブランチで増えた履歴を、現在のブランチへ合流させます。GitHubのPR画面にあるMergeボタンも、提案された変更を基準ブランチへ取り込むためのものです。
GitのmergeとPRは同じではありません。PRは変更を確認・相談する場所で、mergeは履歴を実際に合流させる操作です。
手元でmergeするコマンド例を見る
git switch 基準ブランチ名
git merge 作業ブランチ名
基準ブランチ名にはmainやdevelopなど実際の名前を、作業ブランチ名には実際の作業用ブランチ名を入れ、その作業用ブランチを手元の基準ブランチへ合流させます。チームのルールでPRが必要な場合は、手元で直接mergeせず、その流れに従います。
conflict（コンフリクト）
同じ場所に両立しない変更があり、Gitが自動では選べない状態です。「すべて失敗した」「ファイルが消えた」という意味ではありません。どちらを残すか、またはどう組み合わせるかを人やAIが決めます。
AIには「競合したファイルと双方の意図を説明し、解決案を示して。勝手に片方を捨てないで」と頼めます。
conflictを確認するコマンド例を見る
git status
git diff --name-only --diff-filter=U
二行目は、競合が未解決のファイル名を表示します。
GitHubとやり取りする言葉
local / remote / origin
localは自分のパソコン側、remoteはGitHubなど履歴を送受信する相手です。originは、clone元のリモートに付くことが多い名前です。
originはGitHubそのものを意味する予約語ではなく、接続先に付けた名前です。別の名前を使うプロジェクトや、複数のリモートを持つプロジェクトもあります。
remoteを確認するコマンド例を見る
git remote -v
登録されているリモート名と、取得・送信に使うURLを表示します。URLに認証情報が含まれている可能性がある環境では、共有範囲に注意してください。
fetch
リモートで増えた履歴やブランチの情報を取得します。ただし、現在のワーキングツリーにはまだ取り込みません。
「まずGitHub側の状況だけを確認したい」という場面で使えます。AIには「fetchして差分を説明し、まだmergeやpullはしないで」と頼めます。
fetchのコマンド例を見る
git fetch リモート名
git branch -r
リモート名には実際に登録されている名前を入れます。通常はoriginです。リモートの情報を取得し、リモート側のブランチ一覧を表示します。
pull
リモートの変更を取得し、現在のブランチへ取り込みます。一般にはfetchと、その後のmergeまたはrebaseをまとめて行う操作です。どの方法で取り込むかは設定や指定によって変わります。
作業途中の変更がある状態や、手元とリモートの両方に新しいコミットがある状態では、意図しない競合や履歴の変更につながることがあります。AIには実行前のstatus確認を頼めます。
pullのコマンド例を見る
git switch 基準ブランチ名
git pull --ff-only リモート名 基準ブランチ名
基準ブランチ名にはmainやdevelopなど実際の名前を入れ、リモート名には通常originを入れます。そのリモートの基準ブランチを手元の同名ブランチへ取り込む例です。--ff-onlyを付けると、分岐した履歴の合流が必要な場合は自動で進めず停止します。
push
ローカルで増えたコミットをリモートへ送ります。commitしただけではpushされません。
pushすると、リポジトリの権限を持つ人や連携サービスから変更を見られるようになります。プロジェクトによっては自動テストや公開処理も始まるため、AIには「pushで何が動く設定か」を確認させるとよいでしょう。
pushのコマンド例を見る
git push -u リモート名 作業ブランチ名
リモート名には通常originを、作業ブランチ名には実際の作業用ブランチ名を入れます。そのブランチを初めてリモートへpushする例です。-uで追跡先を設定すると、次回からは通常git pushだけで送れます。
pull request / PR / プルリク
「このブランチの変更を、基準ブランチへ取り込みませんか」と提案するGitHub上の機能です。差分、説明、レビューコメント、自動テストの結果を一か所に集めます。
PRを作っただけでは、通常は基準ブランチへ変更は入りません。レビュー後にmergeして、初めて取り込まれます。
PRを作るコマンド例を見る
GitHub CLIを導入し、認証済みの場合の例です。
gh pr create --base 基準ブランチ名 --head 作業ブランチ名 --fill
--baseの基準ブランチ名にはmainやdevelopなど実際の取り込み先を、--headの作業ブランチ名には実際の作業用ブランチ名を入れます。GitHubのWeb画面から作ることもできます。
作業を退避する・変更を戻す言葉
似た場面で使う言葉ですが、対象が違います。stashは作業途中の変更を一時退避し、restoreは主にコミット前の変更を戻し、revertはコミット済みの変更を新しいコミットで打ち消します。
stash
まだコミットしたくない作業途中の変更を、一時的によけておきます。作業の途中で別のブランチへ移る必要があるときなどに使います。
stashはコミットではありません。何を退避したか分からなくなったり、戻すときに競合したりすることもあります。なお、Gitがまだ追跡していないファイルは通常のstashには含まれません。
stashのコマンド例を見る
git stash push -m "ログイン画面の作業途中"
git stash list
git stash apply
上から順に、一時退避、退避内容の一覧表示、直近の退避内容を戻す操作です。applyでは退避した内容が一覧に残るため、戻したあとのstatusとdiffを確認してから、不要になった退避を削除できます。
restore
ワーキングツリーの変更をコミット済みの状態へ戻したり、変更をステージから外したりします。
git restoreでワーキングツリーを戻すと、まだコミットしていない編集内容を失うことがあります。対象のdiffを確認し、必要なら退避してから使ってください。
restoreのコマンド例を見る
git diff -- 変更したファイルのパス
git restore -- 変更したファイルのパス
git restore --staged 変更したファイルのパス
変更したファイルのパスには、実際に対象とするファイルのパスを入れます。1行目で差分を確認し、2行目で未コミットの変更を捨てます。3行目はステージから外すだけなので、ファイルの編集内容は残ります。
revert
すでにあるコミットの変更を打ち消すための、新しいコミットを作ります。過去の履歴を消さず、「この変更を取り消した」という記録を追加します。
共有済みのコミットを、履歴を書き換えずに戻したい場面でよく使われます。ただし、その後の変更と重なると競合することがあるため、対象コミットと影響を先に確認します。
revertのコマンド例を見る
git log --oneline
git show コミットID
git revert コミットID
コミットIDには、取り消したい実際のIDを入れます。先にgit showで内容を確認してから、git revertを実行します。
reset
ステージの状態や、現在のブランチが指す履歴上の位置を動かします。指定によっては、コミットが現在のブランチの履歴から外れたり、未コミットの変更を失ったりします。特に--hardや、すでに共有した履歴の書き換えは影響が大きい操作です。
初学者がAIに任せるときは、resetの実行をすぐ許可せず、「なぜrestoreやrevertではだめなのか」「どのコミットとファイルがどう変わるのか」「退避は必要か」を先に説明させてください。
reset前の確認コマンドを見る
git status --short --branch
git branch --show-current
git log --oneline -5
git diff
git diff --staged
resetそのものは、目的と共有状況によって安全な指定が変わるため、ここでは一律の実行例を載せていません。
AIには、操作名と停止条件を一緒に伝える
AIにGit作業を頼むときは、「何をするか」だけでなく、「どこで止まるか」も伝えると、意図しない共有や履歴変更を防ぎやすくなります。
調査だけしてほしい
status、現在のブランチ、remote、直近の履歴を確認し、状況を説明してください。ファイル変更、stage、commit、pushはまだ行わないでください。
変更をコミットしてほしい
今回の目的に関係するdiffだけをstageしてください。含めるファイルとコミットメッセージ案を先に示し、私が確認するまでcommitしないでください。
PRまで作ってほしい
手元の基準ブランチがリモートの最新状態と一致するか確認し、そこから作業用ブランチを作ってください。変更、確認、commit、push、PR作成まで進め、PRの取り込み先とテスト結果を報告してください。mergeと公開は行わないでください。
共有済みの変更を戻したい
戻したい変更がcommit済みか、push済みか、merge済みかを確認してください。共有履歴を書き換えずに済む方法を優先し、実行前に影響を説明してください。
「消さないで」「まだpushしないで」「merge前に止めて」のような停止条件は、操作名と同じくらい重要です。
AIの完了報告で確認すること
AIが「Git作業は完了しました」と言ったら、操作名だけでなく、結果を具体的に確認します。
- 現在いるブランチと、作業に使ったブランチ
- 作成したコミットと、その変更内容
- pushしたリモートとブランチ
- PRの取り込み先、URL、現在の状態
- mergeや公開まで行ったのか、そこで止めたのか
これらを報告してもらえば、コマンドを暗記していなくても、作業がどこまで進み、次に何を確認すべきか判断できます。